#34840: Django 4.2 casts text fields when testing IS NULL, preventing use of
partial indexes
-------------------------------------+-------------------------------------
Reporter: Alex Vandiver | Owner: Mariusz
| Felisiak
Type: Bug | Status: assigned
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Florian Apolloner):
Replying to [comment:19 Simon Charette]:
> This approach has existed for a while in the ORM to avoid performing a
query for `filter(somefield__in=[])` as SQL doesn't allow `"column" IN ()`
anyway and we've leaned on it recently to prevent some full table scan on
Postgres (#27397) and issues with `NULL` handling when dealing with
`JSONField` (#34754).
>
> I think it makes sense to use this approach in cases where Python input
poses type ambiguity at the database level like it did with the `IN`
operator, after all we were forced to add `::text` cast because Postgres
doesn't know what the type of `%s IS NULL` should be.
Makes sense. And as we see we only need the `::text` cast in very special
situations, a `.filter(field__isnull=True)` won't require it…
> In all cases the adjustments to `Q.check` to handle `EmptyResultSet`
should be added as other lookups could generate it, the same can be said
about `FullResultSet`.
ACK, and we need tests for both cases. I see that the `WhereNode` properly
propagates `EmptyResultSet`/`FullResultSet` -- I wonder if there are other
cases where we don't do that yet (but I guess we will need to find them on
a case by case basis).
> I think we should not let the discussion about the silencing of
`DatabaseError` die off though and consider a deprecation path to raise
the awareness of the issue. Maybe a possible alternative solution that
doesn't warrant expression introspection (e.g. special casing `RawSQL`)
could be a `Constraint` kwarg that allows disabling model level validation
entirely? That could be a way to silence the warning during the
deprecation period.
+1. Though that should probably be a separate PR/ticket?
As for the indexing issues for people which already created indexes on 4.2
-- we should probably (aside from the release notes) also mention it
explicitly in a blog post? This is something that can be very hard to
find.
--
Ticket URL: <https://code.djangoproject.com/ticket/34840#comment:20>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018ab14ba808-c001d1fc-557e-4541-a0cb-09bcd536dcc7-000000%40eu-central-1.amazonses.com.
