#32781: Made Add/RemoveConstraint operations a noop for unique constraints with
opclasses on SQLite.
-------------------------------------+-------------------------------------
Reporter: Hannes Ljungberg | Owner: Hannes
| Ljungberg
Type: Bug | Status: closed
Component: Migrations | Version: dev
Severity: Normal | Resolution: invalid
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 Hannes Ljungberg):
* status: assigned => closed
* resolution: => invalid
Comment:
> I don't think we should make it a noop. On other databases (MySQL,
Oracle) it creates a unique constraint without opclasses
You're right. I'll close this ticket as the current behaviour on SQLite
when opclasses are specified is to recreate the table with a unique
constraint while ignoring `opclasses` instead of adding a unique index and
this is probably the expected behaviour if expressions or conditions
aren't used.
> +1 to that, IMO Index.opclasses should be deprecated in favour of the
PostgreSQL only OpClass expression.
Yup! Feels like we have a bunch of index-related stuff that should be
deprecated. In addition to the `opclasses` argument;
`Meta.index_together`, `Meta.unique_together` and possibly even
`Index.fields` as we adapt `Index.contains_expressions` to ignore things
that resolve to a `Col`.
--
Ticket URL: <https://code.djangoproject.com/ticket/32781#comment:3>
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/067.9ce373b6bbf56123e06e03581045f1c5%40djangoproject.com.
