While a duplicate check constraint is legal SQL, it normally points to an
error on the part of the developer. We can issue a `Warning` in such a
case.
--
Ticket URL: <https://code.djangoproject.com/ticket/30910>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/11973
--
Ticket URL: <https://code.djangoproject.com/ticket/30910#comment:1>
* stage: Unreviewed => Accepted
Comment:
OK. Seems reasonable. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/30910#comment:2>
* status: new => closed
* resolution: => wontfix
Comment:
Reviewing again with Mariusz, we're not convinced the proposed solution is
sufficiently robust to capture more than the most naive cases. (There are
just too many ways of writing equivalent constraints.) As such, we're not
convinced of the value of the check. (Leaning towards a suspicion it would
actually be unhelpful on balance, which we've seen with other proposed
system checks at times.) Will close on that basis.
Possible to revisit if a way of ''reducing'' semantically equivalent
constraints turns up...
(c.f. [https://github.com/django/django/pull/11973 Discussion on PR].)
--
Ticket URL: <https://code.djangoproject.com/ticket/30910#comment:3>