summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql/selectable.py
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2014-03-27 20:38:46 -0400
committerMike Bayer <mike_mp@zzzcomputing.com>2014-03-27 20:38:46 -0400
commit825d3b0d6db4b4db78d69b9dcf012c5f627385d3 (patch)
tree6f810b48a856c969b6c107f8b987e5b0686450b4 /lib/sqlalchemy/sql/selectable.py
parent0611baa889198421afa932f2af1524bd8826ed7d (diff)
downloadsqlalchemy-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 'lib/sqlalchemy/sql/selectable.py')
0 files changed, 0 insertions, 0 deletions