On Nov 10, 2006, at 12:13 AM, Daniel Miller wrote:
> This query:
>
> q.select(or_(
> c.orders.items.item_name == 'item#4',
> c.orders.items.item_name == 'item #5'
> ))
>
>
> Should generate something similar to this SQL:
>
> SELECT ...
> FROM users u
> INNER JOIN orders o
> ON u.user_id = o.user_id
> INNER JOIN items i
> ON o.order_id = i.order_id
> WHERE i.item_name = 'item#4'
> OR i.item_name = 'item #5'
>
>
> For the given clause, each occurrence of User.c.orders.items is
> combined into a single join path from users to items, and every
> occurrence of 'item_name' uses the same table alias 'i'. Is that
> too simplistic? Here are a few more examples:
>
its kind of what SQL construction does now, i.e. extracts unique
"FROM" objects from the where criterion and adds them to a list, so
the approach would probably work (might possibly have other issues we
arent thinking of just yet)
>
> Notice how the join path for Users.c.orders is superimposed on the
> join path for Users.c.orders.items. It should be possible to use
> the alias function to force separate joins like this:
>
> q.select(and_(
> c.orders.alias('ox').order_total > 50,
> or_(
> c.orders.alias('o').items.item_name == 'item #4',
> c.orders.alias('o').items.item_name == 'item #5',
> )
> ))
> ....
>
> ASIDE: One thing we might want to change is the 'alias' function.
> Since the 'orders' table may have a column named 'alias', it might
> be better to make it a stand-alone function like this:
>
> alias(c.orders, 'ox')
>
i think this is the problem when you start munging namespaces
together, as opposed to grouping them under explicit prefixes (i.e.
'c'). so far I think this new syntax is going to be confusing to
people since its not explicitly clear what it means underneath (which
leaves people to guess, get it wrong, and then report it as bugs/
confusion), and also presents a completely different way to create
joins when we already have more explicit ways to do it (inlcuding the
selectresults "transformative" style which i think is very fast and
clear). when you start throwing aliases into the mix i think it
becomes more overwhelming.
compare to the current method:
ox = ordertable.alias('ox')
q.select(and_(ox.c.order_total > 50, or_(itemtable.c.item_name=='item
#4', itemtable.c.item_name=='item #5')), from_obj=[users.join
(ordertable).join(itemstable).join(ox, users.c.user_id==ox.c.user_id)])
more explicit...but I think clearer. the user definitely knows what
they are doing when they do this (note that from_obj hasnt really
worked in query() up until version 0.3.0 which is why it looks less
familiar, but i think also aids in creating more complex queries). i
think people should be expressing exactly the joins they want if they
want to be joining at all.
I think your original proposal, i.e. User.c.orders == someorder is
reasonable since its hard to misunderstand what that does.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
