[Django] #32781: Made Add/RemoveConstraint operations a noop for unique constraints with opclasses on SQLite.
Django
opclasses on SQLite.
-------------------------------------+-------------------------------------
Reporter: Hannes | Owner: Hannes Ljungberg
Ljungberg |
Type: Bug | Status: assigned
Component: | Version: dev
Migrations |
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 |
-------------------------------------+-------------------------------------
It currently recreates the table.
Related: https://code.djangoproject.com/ticket/32780
--
Ticket URL: <https://code.djangoproject.com/ticket/32781>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
opclasses on SQLite.
-------------------------------------+-------------------------------------
| Ljungberg
Type: Bug | Status: assigned
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 Mariusz Felisiak):
I don't think we should make it a noop. On other databases (MySQL, Oracle)
it creates a unique constraint without `opclasses` as
[https://docs.djangoproject.com/en/3.2/ref/models/constraints/#opclasses
documented]: ''"opclasses are ignored for databases besides PostgreSQL"''
and IMO expected. `opclasses` are really PostgreSQL-specific and on other
databases default operators are just fine.
--
Ticket URL: <https://code.djangoproject.com/ticket/32781#comment:1>
Django
opclasses on SQLite.
-------------------------------------+-------------------------------------
| Ljungberg
Type: Bug | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
> `opclasses` are really PostgreSQL-specific and on other databases
default operators are just fine.
+1 to that, IMO `Index.opclasses` should be deprecated in favour of the
PostgreSQL only `OpClass` expression.
--
Ticket URL: <https://code.djangoproject.com/ticket/32781#comment:2>
Django
opclasses on SQLite.
-------------------------------------+-------------------------------------
| Ljungberg
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
-------------------------------------+-------------------------------------
* 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>