On May 26, 2011, at 11:02 AM, Israel Ben Guilherme Fonseca wrote:
> Hi, > > Just a easy question, why we don't have a contains_eager_all like we do with > joinedload? contains_eager() should always act in an "all" context since there's little use otherwise. This was fixed in 0.7 and is ticket #2032: http://www.sqlalchemy.org/trac/ticket/2032 07Migration is updated. > > By the way, I don't exactly understand why we shouldn't use the _all version > always. You might want to load a list of A, each has a collection of B. But you don't want the B's by default. But, if you do in fact load a particular collection of B, you'd like them to eagerly load their C. We're falling victim a bit to favoring a rare use case over a common one here, but that's how things have worked out and its not really worth changing around at this point. > > > Bonus question: Wouldnt be nice if the joinedload (and all the variants) > could be used in the Query object? Ex: > > query(User).joinedload('orders').all() is much more readable than: > query(User).options(joinedload('orders').all() Again this is how things have worked out over the years, but also options() does have a use in that you can also make your own MapperOption objects, without any need to subclass Query. So there is some consistency in that options() allows external functions to enter in and modify the state of Query, without Query having any awareness of them. -- 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.
