diff options
| author | Mike Bayer <mike_mp@zzzcomputing.com> | 2014-03-27 20:38:46 -0400 |
|---|---|---|
| committer | Mike Bayer <mike_mp@zzzcomputing.com> | 2014-03-27 20:38:46 -0400 |
| commit | 825d3b0d6db4b4db78d69b9dcf012c5f627385d3 (patch) | |
| tree | 6f810b48a856c969b6c107f8b987e5b0686450b4 /doc | |
| parent | 0611baa889198421afa932f2af1524bd8826ed7d (diff) | |
| download | sqlalchemy-825d3b0d6db4b4db78d69b9dcf012c5f627385d3.tar.gz | |
- 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
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/build/changelog/changelog_09.rst | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/build/changelog/changelog_09.rst b/doc/build/changelog/changelog_09.rst index f2594b733..321deb647 100644 --- a/doc/build/changelog/changelog_09.rst +++ b/doc/build/changelog/changelog_09.rst @@ -16,6 +16,25 @@ .. change:: :tags: bug, orm + :tickets: 2948 + + 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. + + .. change:: + :tags: bug, orm :tickets: 2965 Improved the check for "how to join from A to B" such that when |