[Django] #34959: Q(a=b) and Exact(a, b) handle NULLs differently

[Django]

#34959: Q(a=b) and Exact(a, b) handle NULLs differently
-------------------------------------+-------------------------------------
Reporter: Roman | Owner: nobody
Odaisky |
Type: Bug | Status: new
Component: Database | Version: 5.0
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
||= Expression =||= SQL =||
|| Q(f=42) || m.f = 42 ||
|| ~Q(f=42) || NOT(m.f = 42 AND m.f IS NOT NULL) ||
|| Exact(F("f"), 42) || m.f = (42) ||
|| ~Exact(F("f"), 42) || NOT m.f = (42) ||

~Q tries to treat SQL NULLs like Python None values, ~Exact doesn’t, so Q
| ~Q covers the entire table while Exact | ~Exact omits the null values.
Given that people who need to use lookups, F objects, functions and so on
are most likely doing something complex, I doubt it’s advisable or even
possible to extend the null-as-None behavior to every possible expression
(the `in` lookup doesn’t try to do that, for example). But in this case
the documentation should be very clear that the discrepancy exists and Q
objects do extra magic that the lookups do not.

Another option is to deprecate the `~` operator on anything but Q objects,
and force people to use `NegatedExpression` (hopefully aliased to `Not`)
so it’s explicit it doesn’t do the same thing as ~Q.

By the way, the magic can easily backfire with custom lookups:
{{{
def lookupify(function):
class LookupifyLookup(Lookup):
prepare_rhs = False

def as_sql(self, compiler, connection):
return compiler.compile(
function(self.lhs, self.rhs)
.resolve_expression(compiler.query)
)

return LookupifyLookup

Field.register_lookup(
lookupify(
lambda x, y: Exact(Exact(x, 0) | IsNull(x, True), y),
),
"isblank",
)

SomeModel.objects.exclude(field__isblank=True)
# will exclude zeroes but not nulls!
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/34959>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#34959: Q(a=b) and Exact(a, b) handle NULLs differently
-------------------------------------+-------------------------------------

Reporter: Roman Odaisky | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 5.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Simon Charette):

It seems like the exact same bug as #34959 that has
[https://github.com/django/django/pull/16817/ a proposed implementation
that allows expressions to denote how they handle nulls].

--
Ticket URL: <https://code.djangoproject.com/ticket/34959#comment:1>

[Django]

#34959: Q(a=b) and Exact(a, b) handle NULLs differently
-------------------------------------+-------------------------------------
Reporter: Roman Odaisky | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 5.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by David Sanders):

* cc: David Sanders (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/34959#comment:2>

[Django]

#34959: Q(a=b) and Exact(a, b) handle NULLs differently
-------------------------------------+-------------------------------------
Reporter: Roman Odaisky | Owner: nobody

Type: Bug | Status: closed

Component: Database layer | Version: 5.0
(models, ORM) |

Severity: Normal | Resolution: duplicate

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Natalia Bidart):

* status: new => closed
* resolution: => duplicate

Comment:

Thank you Simon, after reading the bugs I agree this looks like a
duplicate. Closing as such!
Duplicate of #32398

--
Ticket URL: <https://code.djangoproject.com/ticket/34959#comment:3>