On Nov 9, 2006, at 10:20 PM, Daniel Miller wrote:
> > Can you give an example of the SQL (including the joins) that would > be generated by your statement above? > (user.user_id=orders.user_id AND orders.order_id=items.order_id AND items.item_name='item #4') OR (user.user_id=orders.user_id AND orders.order_id=items.order_id AND items.item_name='item #5') > > Right. It should be possible (although I'm not sure how simple) to > combine conditions using the rules for combining logical > expressions (i.e. commutative, transitive, etc.). For example: > > (A == B AND C == D) OR (A == B AND C == E) > > can be reduced to > > (A == B) AND (C == D OR C == E) > > So what we need is a way to take a group of expressions and reduce > them to their simplest form before generating the SQL. However, > don't most main-stream databases do this kind of optimization > anyway? MySQL does (http://dev.mysql.com/doc/refman/5.0/en/where- > optimizations.html). > this is what i was getting at; an innocent feature is already spawning complicated expression parsing before we've even written any code. Its possible the databases optimize a clause like the above...then again i dont know if this approach is always going to come up with a valid clause. by adding our own syntaxes, as opposed to using syntaxes that always map directly to SQL, we just dont know (since im not a language syntax expert). > Having said all that, it may be simpler to use join_to/join_via in > some cases and maybe that's a good reason to keep those functions > around. However, I think this new syntax would still be very > valuable in many cases. Being able to say user.c.orders==someorder is not a big deal. user.c.orders.items compiling into a Join (or into the join clause ? im not sure) im still not sure how that would be used (i.e. do you stick it in the WHERE criterion or in the from_obj)? The syntax I like best is the one provided by the selectresults extension, where you can just say (well, it has just join_to right now, but this is the idea): query.select().join_via('orders', 'items').select (Item.c.item_name=='item #4') this is also very clear if you want to outerjoin: query.select().outerjoin_via('orders', 'items').select() its quick and its explicit. users.c.orders.items seems more ambiguous. ive been concerned that SelectResults is not easy enough to use (i.e. you need a mapper extension, or a separate SelectResults construction). im thinking it should be built-in to Query somehow, i.e. just say query.selectresults() and start building (but even that's too verbose). Im still wondering if Query should have just been built that way from the start - using a strictly transformative interface instead of keyword-args-based. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
