[sqlalchemy] Why we don't have a contains_eager_all?
Hi,
Just a easy question, why we don't have a contains_eager_all like we do with
joinedload?
By the way, I don't exactly understand why we shouldn't use the _all version
always.
Example (from
http://www.sqlalchemy.org/docs/orm/loading.html?highlight=contains_eager#contains-eager
):
query(User).options(contains_eager('orders', 'items'))
With this we are only loading the items of the orders objects. But to access
it, I must pass through the orders relation anyway, but without another:
contains_eager('orders')
It would make a new select, so I didn't get whats the use case of eager
loading the deepest children without loading all the way to it too.
(or maybe I'm wrong and it's behavior is like what I said and I'm missing
something in my tests)
Thanks in advance,
--
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()
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Why we don't have a contains_eager_all?
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 sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Why we don't have a contains_eager_all?
Hmm, nice, I'm still with the 0.6.7, so that's why I missed it.
Thanks again for the superfast-effective answer.
2011/5/26 Michael Bayer mike...@zzzcomputing.com
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 sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
