----- "Bill Peck" <bpeck(a)redhat.com> wrote:
From: "Bill Peck" <bpeck(a)redhat.com>
To: "List for the development of the Beaker project"
<beaker-devel(a)lists.fedorahosted.org>, "Raymond Mancy"
Sent: Tuesday, November 24, 2009 4:46:41 AM GMT +10:00 Brisbane
Subject: search implementation using synonym and Select
The search is working and its much better than anything I did so far.
:-) But I'm hitting a few issues with the way its implemented.
For example in the System mapper we have this:
'Arch' here is a sub-select column label. In the beaker code, this column_property
is only accessed if the System/Arch is being searched on.
If the System/Arch is being searched on than other tables will be joined in the query. At
that point, System.Arch will work as intended.
Actually System/Arch is kind of unique in that it's represents a one to many
relationship, this means the code around it is a bit more complex then say, System/Owner.
even though we also have the following as well:
'arch' here is the relationship between the Arch class and the System class.
Internally, 'Arch' and 'arch' are not confused.
<error code snipped>
There must be a better way to do what we want here.. Any thoughts?
Possibly there is a better way of implementing this. I did it this way for a few reasons.
Firstly, when we create our drop down in beaker of 'Table/Column', it makes it
easier to determine what we can search on. We can only search on things that are
represented as a column within SQLalchemy.
This means we can do things like automatically include all columns as part of the search,
or selectively exclude some. Not a huge deal, but maybe handy.
In SQLAlchemy we actually turn them into a column. Some of the things that we search on
are actual columns of the table in the db(i.e System/Serial,
where serial is a column of the System table), but many things we search on are just a
relationship (i.e System/Owner). So mapping the relationship as a column
means throughout the rest of the code we don't have to figure out whether or not
it's an actual column. The rest of the code can be much simpler and more consistent.
It makes it very easy to figure out the column type (which we then use to determine what
oeprations can be done), the code that builds the query is much simpler etc.
These were some of my goals when thinking about how to do the search. I'm sure there
are caveats to it as well.