Opened 3 years ago
Closed 3 years ago
#32781 closed Bug (invalid)
Made Add/RemoveConstraint operations a noop for unique constraints with opclasses on SQLite.
Reported by: | Hannes Ljungberg | Owned by: | Hannes Ljungberg |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
It currently recreates the table.
Change History (3)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
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.
comment:3 by , 3 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
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
.
I don't think we should make it a noop. On other databases (MySQL, Oracle) it creates a unique constraint without
opclasses
as 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.