On Sep 4, 2008, at 7:19 PM, Jon wrote:
> >> In your specific case, I don't see what's so hard about creating a >> Query which has *only* those aspects which make sense both to a get() >> as well as a join()/order_by() combination (in this case the >> eagerload >> options), and passing that to further functions. The "backwards" >> behavior you're looking for, i.e. that a bunch of state set up on >> Query would essentially be arbitrarily "ignored", suggests that your >> application might be easier to understand if you rearranged it to not >> rely upon that behavior. > > In this case it means a doubling of the number of queries I already > have, and those queries are indexed by name. Since the queries > (sometimes fairly complex) would be almost exactly the same it would > actually make things much harder to understand. Currently, the only > special case I have is whether to use get(X) or filter/filter_by + > all(). im curious, since a Query is pretty much tied to a Session, how is that working in your application ? Is it using just a single long- running session ? > However, I'd much rather discuss things from a different > standpoint. Let me rephrase the question - what is /wrong/ (not / > nonsensical/) about combining order_by with get(X)? The only > difference in the SQL generated is, in fact, the ORDER BY which > shouldn't matter. get() actually has an explicit line that erases the "order_by" even if one is present. 0.4 should be doing that but i havent checked lately if thats covered. in 0.5 the mapper-level order_by() happens differently so I know why it might not be working (suggesting its not covered either). > I guess I'm following the philosophy of: if it doesn't hurt, and it > makes some things easier or clearer, then it's fine. This seems to no > different than bash suddenly proclaiming that "cat FILE | grep ..." > won't work any more because the cat is gratuitous. I'd like to hear what other folks have to say since 0.4's query had this attitude - you could have filter(), order_by(), whatever you want set up, and get() would just ignore all that and do its thing. There was general agreement that this was too open ended. In this case I dont see order_by() as different from the others; theyre all things that get() just ignores (or complains about). > One might argue that get(X) itself is superfluous because, hey, > applications might as well just use filter/filter_by and check for > 1 > return value themselves. get() does have a different behavioral contract since it can locate directly from the Session if present. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
