i just wanted to add a general comment to this discussion... the kinds
of things you're doing fall into a category im calling "polymorphic
filtering". Whereas SQLA started gaining the ability to load objects
polymorphically in version 0.3, its only now that we are starting to
get into the idea of the Query object also being able to filter from
arbitrary subclasses without too much headache....we have a few new
features in trunk with regards to this which were in response to
another user doing similar kinds of things (joining to a polymorphic
class, specifying filter criterion on a subclass).
If you look at the history of a method on Query like join(), you'd see
that early on we didnt have join(); we said, "oh just set up the
joining criterion manually", as well as "just select from that join,
i.e. table1.join(table2)". And of course people complained since the
information to create the join is present in the relation() already,
so why type it twice.
So we first added some somewhat hacky features like join_to() and
join_via() to help in constructing these joins and eventually the much
cleaner join() call, as well as some other query helpers like has()
and any() which also "join" to other tables. But join() is way more
complicated than it appeared at first; it can generate aliases, attach
its joins to a wide variety of parent tables other than the default
mapped table, and can add the joined table to the columns clause of
the select. It has taken a very long time to get right.
Polymorphic filtering is now the feature which is at this stage; we
have a lot of new capabilities added to select_from() as well as
join() to support querying multiple classes based on criterion against
more than one subclass, but theres still some manual intervention. We
also have yet to bite the bullet and make the"select_table" argument
on mapper() something that can generate automatically, since in that
case there are some complicating scenarios (like concrete tables, etc)
which make that very challenging to do generically.
What we're willing to do here is to generate SQL from things we
know....like query.join('somerelation') can generate a join since it
already knows the ON clause, a feature like
query.polymorphic_with(Engineer).polymorphic_with(Manager) would be
the style thats acceptable here; its not "implicit" but does not
require repeating redundant information (i.e. the join criterion
between parent and child table). Of course if the relation between
Person and Engineer were concrete (as opposed to joined table
inheritance), its a lot harder to generate a UNION so we might have to
raise an error on that one for now.
So I guess my point here is that the stuff you're looking for is an
area right where SA's development has found itself, and this is why we
continue to have very low version numbers....we develop slowly in sort
of a symbiotic relationship with user needs. Consider the stumbling
blocks here part of the process :).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
