Changes between Version 2 and Version 3 of Ticket #32043, comment 3


Ignore:
Timestamp:
Sep 25, 2020, 3:58:43 PM (4 years ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #32043, comment 3

    v2 v3  
    1616If that's the case then I fear we cannot change the current behaviour without causing massive backward incompatibilities.
    1717
    18 For example `filter(nullable_field=F('nullable_field'))` doesn't result in `WHERE nullable_field = nullable_field OR (nullable_field IS NULL AND nullable_field IS NULL)` so making this change only for resolved `OuterRef` would make the current behaviour even more inconsistent. The ORM does a relatively good job at abstracting the triple-boolean logic of SQL when provided literal values (e.g. `None` handling in `exclude()`) but it doesn't deal with nullable expressions for performance reasons (hard to determine if complex expressions are nullable and `OR` clauses required for `IS NULL` makes the job of the query planner harder).
     18For example `filter(nullable_field=F('other_nullable_field'))` doesn't result in `WHERE nullable_field = other_nullable_field OR (nullable_field IS NULL AND other_nullable_field IS NULL)` so making this change only for resolved `OuterRef` would make the current behaviour even more inconsistent. The ORM does a relatively good job at abstracting the triple-boolean logic of SQL when provided literal values (e.g. `None` handling in `exclude()`) but it doesn't deal with nullable expressions for performance reasons (hard to determine if complex expressions are nullable and `OR` clauses required for `IS NULL` makes the job of the query planner harder).
Back to Top