Tags: ormar-orm/ormar
Tags
Fix cartesian product when filtering on two FKs to the same target (#… …1708) * fix: avoid cartesian product when filtering on two FKs to the same target (#1706) The filter (WHERE) side chose which of two converging relation paths got a complex alias by relation_str length, while the join builder uses depth-first order, so equal-length siblings (e.g. a_port__switch / z_port__switch) were assigned opposite aliases and the filter referenced a table the join never created. Complex aliases also linger in the globally shared alias manager, so a later, simpler query could pick one up and reference an unjoined table. Walk relation paths in the same depth-first order as the join (first occurrence keeps the basic alias, later ones go complex) and only reroute filters whose key is a duplicate registered for the current query. * chore: release 0.26.0, require ormar-utils>=0.2.0 Bump version to 0.26.0 and require ormar-utils>=0.2.0 so installs pull the stable-ABI (abi3) wheel that works on Python 3.10+ including 3.14 (#1702). Roll the accumulated Unreleased notes into the 0.26.0 section and add the cartesian-product fix (#1706) and the ormar-utils requirement bump (#1702).
chore(release): prepare 0.24.0 (#1636) Bump version and add release notes for 0.24.0. Features: - on_update field option (#1273) - fk_name override on ForeignKey (#849) - forward autoincrement to SQLAlchemy column (#674) Fixes: - run standalone queries under AUTOCOMMIT isolation, restoring 0.21-era per-row CRUD performance (#1629, #1635) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PreviousNext