On Feb 28, 2014, at 12:09 PM, Jonathan Vanasco <jonat...@findmeon.com> wrote:
> If this behavior is a bug , I can build out a testcase. FWIW , I think it's
> a bug.
>
> class Foo :
> id = int primary key
> bar = relationship(bar)
> baz = relationship(baz)
>
>
> # hits the db
> a = session.query( Foo ).get(1)
>
> # doesn't hit the db
> b = session.query( Foo ).get(1)
> c = session.query( Foo ).options( joinedload('bar'),
> subqueryload('baz')).get(1)
>
> # hits the db
> print c.bar
> print c.baz
>
> shouldn't `c` hit the database , in order to pull the explicitly requested
> eager loaded options ?
nope. get() means, “the SELECT may not happen”. eager loads are always
secondary to the fact that the row is being loaded. if you want to definitely
load the row, say filter_by(id…).first().
>
> if not, is there a way to trigger this ? I need to load all the
> "eagerloaded" attributes before we push data into the templates. i could do
> this manually on each .get(), but that would be way uglier than anything
> official.
Poking at the source this may sort of do most of what you want if you say
query.populate_existing().get(1). the components to make this operation occur
are there but they aren’t put together into a tested API (test coverage and
documentation are the main things that make it slow to add things like this
officially).
signature.asc
Description: Message signed with OpenPGP using GPGMail
