On 6/3/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > im giong to look into optimizing the cloning. as ive said, > hibernate's criteria object behaves "generatively" but doesnt > actually copy the object; several folks here seem to want the > "generativeness". ive been considering sneaking in a flag/method > that would turn off the "generativeness" but id have to make sure you > dont notice it :).
Does that mean returning the results immediately, or modifying the query in place and returning it? Maybe modifying the query in place and returning it isn't such a bad idea after all, considering that this is kind of a special case, having to call so many methods to build up a query. Most other OO systems don't require so many method calls to build up a meaningful object, but most other OO systems are not SQL queries either. And if it provides a way to get away from "q = q.filter(...)" in favor of "q.filter(...)", that would be an advantage. It gets tiring assigning the same variable to itself again and again when assignment isn't really the nature of what's going on. > > It would still be worth a separate proposal to reform assignmapper; > > i.e., delete the query methods .foo() that duplicate > > MyClass.query().foo(). A lot of non-Exilir people use assignmapper, > > and it's frustrating that .select() exists but .filter() doesn't, so > > either add the missing methods or delete the redundant ones. > > filter() and filter_by() were added in 0.3.8. Hooray. I've been following the trunk and reading the CHANGELOG but I didn't notice that feature. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
