[Sqlalchemy-tickets] Issue #3187: Eager loading not working when entity in identity_map (zzzeek/sqlalchemy)

[Aidan K. <iss...@bi...>]

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 :)