Answering my own question.
Here's a patch that seems to fix it, but I am uncertain about whether it
breaks other things. Use at your own risk, at least until someone more
familiar with this code evaluates it.
Index: lib/sqlalchemy/orm/strategies.py
===================================================================
--- lib/sqlalchemy/orm/strategies.py (revision 114304)
+++ lib/sqlalchemy/orm/strategies.py (working copy)
@@ -1474,20 +1474,24 @@
def _create_scalar_loader(self, context, key, _instance):
def load_scalar_from_joined_new_row(state, dict_, row):
# set a scalar object instance directly on the parent
# object, bypassing InstrumentedAttribute event handlers.
dict_[key] = _instance(row, None)
def load_scalar_from_joined_existing_row(state, dict_, row):
# call _instance on the row, even though the object has
# been created, so that we further descend into properties
existing = _instance(row, None)
+ if key in dict_:
+ assert dict_[key] is existing
+ else:
+ dict_[key] = existing
if existing is not None \
and key in dict_ \
and existing is not dict_[key]:
util.warn(
"Multiple rows returned with "
"uselist=False for eagerly-loaded attribute '%s' "
% self)
def load_scalar_from_joined_exec(state, dict_, row):
_instance(row, None)
- Dave
On 9/2/2015 7:29 PM, Dave Vitek wrote:
Hi all,
I've come across what I'm pretty sure is a bug with contains_eager
when there are multiple joinpaths leading to the same row, and only
some of those joinpaths are using contains_eager all they way down the
joinpath.
I've prepared a test case:
http://pastebin.com/CbyUMdqC
See the text at the top of the test case for further details.
- Dave
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
