You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
select_related and load_related are core ORM features but currently have 2 tests each, covering only the forward to-one happy path. This is the highest-regression-risk area before 1.0.
Cases to cover (both Postgres + MySQL)
select_related (JOIN): forward to-one; multiple forward relations in one call; NULL FK → relation is None; missing/None related row; composition with filter/order_by/limit.
load_related (batched): forward, reverse (list[...]), nested (a__b); empty result set; object with no related rows → empty list / None; multiple roots sharing a related object (dedupe); N+1 avoidance (one query per relation level).
Cross-cutting: explicit ValueError when only()/defer() combined with select_related() (guard added in Load only given subset of fields from DB #50); relation fields excluded from to_dict() by default.
Done when
Each case above is a test, green on both backends; any bug surfaced is filed as its own issue and fixed.
Why
select_relatedandload_relatedare core ORM features but currently have 2 tests each, covering only the forward to-one happy path. This is the highest-regression-risk area before 1.0.Cases to cover (both Postgres + MySQL)
None; missing/None related row; composition withfilter/order_by/limit.list[...]), nested (a__b); empty result set; object with no related rows → empty list / None; multiple roots sharing a related object (dedupe); N+1 avoidance (one query per relation level).ValueErrorwhenonly()/defer()combined withselect_related()(guard added in Load only given subset of fields from DB #50); relation fields excluded fromto_dict()by default.Done when
Each case above is a test, green on both backends; any bug surfaced is filed as its own issue and fixed.