Fixed #20024 -- Corrected handling of __in lookups with None in exclude querysets to match SQL semantics. #20027
Conversation
… exclude querysets to match SQL semantics.
There was a problem hiding this comment.
Thanks for the PR!
@charettes reviewed #19691, so he might have some thoughts.
| # into subquery above | ||
| self.assertIs(inner_qs._result_cache, None) | ||
|
|
||
| @unittest.expectedFailure |
There was a problem hiding this comment.
There were some tests included with #19691 we should add.
There was a problem hiding this comment.
The composite pk one seems valuable, not sure about the other one though 🤔
| clause.add(lookup_class(col, False), AND) | ||
| if ( | ||
| lookup_type == "in" | ||
| and isinstance(condition.rhs, (list, tuple)) |
There was a problem hiding this comment.
This should accept any iterable.
There was a problem hiding this comment.
It's unfortunate that we have to hardcode this logic here but hopefully #16817 would allow us to revisit this properly by having lookups.In.exclude_nulls return the proper constraint.
| clause.add(lookup_class(col, False), AND) | ||
| if ( | ||
| lookup_type == "in" | ||
| and isinstance(condition.rhs, (list, tuple)) |
There was a problem hiding this comment.
It's unfortunate that we have to hardcode this logic here but hopefully #16817 would allow us to revisit this properly by having lookups.In.exclude_nulls return the proper constraint.
| # into subquery above | ||
| self.assertIs(inner_qs._result_cache, None) | ||
|
|
||
| @unittest.expectedFailure |
There was a problem hiding this comment.
The composite pk one seems valuable, not sure about the other one though 🤔
4 participants
Trac ticket number
ticket-20024
Branch description
Problem
The SQL generated by an exclude queryset is not semantically aligned with the queryset when using
__inlookups containingNone.Solution
The PR updates
WhereNodeto useORand generateIS NULLfor correct SQL semantics in this case.Checklist
mainbranch.