[Sqlalchemy-tickets] Issue #3187: Eager loading not working when entity in identity_map (zzzeek/sql
Brought to you by:
zzzeek
|
From: Aidan K. <iss...@bi...> - 2014-09-06 10:23:25
|
New issue 3187: Eager loading not working when entity in identity_map https://bitbucket.org/zzzeek/sqlalchemy/issue/3187/eager-loading-not-working-when-entity-in Aidan Kane: I'm seeing slightly surprising behaviour around loading options when an entity is already in the session identity_map. I've attached a self-contained test case so you can more easily see what I mean. Depending on how you query for an entity (get() vs .filter().one()) you get different loading behaviour if the entity is already in the identity_map. In the simplest case: ``` #!python x = session.query(A).get(1) # the loading options are ignored here x = session.query(A).options(...loading_options...).get(1) # while they're honoured here x = session.query(A).options(...loading_options...).filter(A.id==1).one() ``` To run my test case: ``` #!python import loading_behaviour_bug loading_behaviour_bug.setup() # subquery loading works loading_behaviour_bug.test_expected1() # subquery loading works loading_behaviour_bug.test_expected2() # subquery loading doesn't work loading_behaviour_bug.test_unexpected() ``` I suspect this might be expected behaviour but I couldn't find anything about it in the docs. Whenever you call get() it's coming from the identity_map, and it may have different children than those in the db (because another bit of code has made a change / dirtied the object) - though I would have thought that would be ok because it's in the same transaction. My issue is that depending on what code has run up to this point I can't use .get() because I can't trust the eager loading to run (my current workaround is to use the filter().one() pattern in critical bits of code). It might that I just need a little more management around the scope of the unit-or-work but you can see how easy it would be to get this wrong (especially in a web application where the recommendation is to tie the unit-of-work to the entire request). Then again, I may have just completely missed something because it seems implausible to me that I could find anything resembling a bug in SQLA :) |