On Sep 4, 7:01 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > > 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 ?
I create and destroy (close, actually) a session for each request. Essentially, at the beginning of a request the base query for each type of object is built and then passed around quite a bit. From a certain perspective, it's entirely serial as the only state is that which is passed around rather than stored somewhere. > > 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). When /not/ using get: 0.4.6 and 0.5b3 are both passing the order by /specified at the ORM layer/ through. I'm talking about when defining the mapper I specify an order_by, *not* when I'm building the query. When using get: 0.4.6 appears to strip the order_by (when specified by the query) on get, although the order_by specified in the mapper remains. 0.5b3 grumps, of course. > 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). For filter and such, yes, I can see that as very confusing - I've specified conditions which should determine the final result but they don't. On the other hand, order_by (and probably some others) are such that they do /not/ alter the final result. > > 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. I did not know that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
