#36592: Allow UniqueConstraint's nulls_distinct to accept a database's default
value rather than raising a system check error
-------------------------------------+-------------------------------------
Reporter: Russell Owen | Owner: (none)
Type: New feature | Status: closed
Component: Database layer | Version: 5.2
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: SQLite | Triage Stage:
UniqueConstraint | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):
* resolution: => wontfix
* status: new => closed
* summary:
Incorrect warning when specifying a UniqueConstraint with SQLite and
nulls_distinct=False
=>
Allow UniqueConstraint's nulls_distinct to accept a database's default
value rather than raising a system check error
* type: Bug => New feature
Comment:
I understand your proposal, but it's not how `nulls_distinct` was designed
to be used. The documentation states, "Unique constraints with
`nulls_distinct` are ignored for databases besides PostgreSQL 15+." Your
proposal to change the behavior to make the attribute a flag that has some
relation to a database's default treatment of null values is a new feature
rather than a bug. For new features, you need to find consensus on the
DevelopersMailingList. If there is consensus to change the behavior, we'll
reopen the ticket.
A concrete use case would help your argument. I'm skeptical that a user
defining:
{{{
UniqueConstraint(
name="simple_unique_constraint",
fields=["field_a", "field_b"],
nulls_distinct=False,
)
}}}
should mean "I want a unique constraint, but only on databases where nulls
aren't treated as distinct."
--
Ticket URL: <
https://code.djangoproject.com/ticket/36592#comment:6>
Django <
https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.