Opened 12 years ago
Last modified 4 years ago
#20024 new Bug
'exclude' does not work with lists containing a 'None' element. — at Version 3
Description (last modified by ) ¶
For example:
Entry.objects.exclude(foo__in=[None, 1])
It is supposed to return all items whose foo field is not None or 1, but it actually returns an empty query set.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR].
Change History (3)
comment:1 by , 12 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|---|
| Type: | Uncategorized → Bug |
comment:2 by , 12 years ago
Let's not be too smart... NULL in SQL is nowhere near as consistent as None in Python because of SQL's tri-valued boolean logic; we cannot hide this.
comment:3 by , 12 years ago
| Description: | modified (diff) |
|---|
Note:
See TracTickets
for help on using tickets.
This is a known failure (tested in queries/tests.py, test_col_not_in_list_containing_null()).
This is somewhat hard to fix as SQL's "somecol NOT IN lst_containing_null" is weird - it will always return False (well, technically UNKNOWN but this doesn't matter here), and this is what causes the bug.
It would be possible to check for presence of None in the given list. If present, remove it and add in a proper IS NULL check instead. But then a query like
.exclude(somecol__in=qs_containig_null)would work differently from.exclude(somecol__in=list(qs_containig_null)). I guess that could be classified as known abstraction leak.