]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
- Fixed a very old behavior where the lazy load emitted for a one-to-many
authorMike Bayer <mike_mp@zzzcomputing.com>
Fri, 28 Mar 2014 00:38:46 +0000 (20:38 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Fri, 28 Mar 2014 00:38:46 +0000 (20:38 -0400)
commit825d3b0d6db4b4db78d69b9dcf012c5f627385d3
tree6f810b48a856c969b6c107f8b987e5b0686450b4
parent0611baa889198421afa932f2af1524bd8826ed7d
- Fixed a very old behavior where the lazy load emitted for a one-to-many
could inappropriately pull in the parent table, and also return results
inconsistent based on what's in the parent table, when the primaryjoin
includes some kind of discriminator against the parent table, such
as ``and_(parent.id == child.parent_id, parent.deleted == False)``.
While this primaryjoin doesn't make that much sense for a one-to-many,
it is slightly more common when applied to the many-to-one side, and
the one-to-many comes as a result of a backref.
Loading rows from ``child`` in this case would keep ``parent.deleted == False``
as is within the query, thereby yanking it into the FROM clause
and doing a cartesian product.  The new behavior will now substitute
the value of the local "parent.deleted" for that parameter as is
appropriate.   Though typically, a real-world app probably wants to use a
different primaryjoin for the o2m side in any case.
fixes #2948
doc/build/changelog/changelog_09.rst
lib/sqlalchemy/orm/relationships.py
test/orm/test_lazy_relations.py
test/orm/test_rel_fn.py