Request for comments about a ticket: Index vs UniqueConstraint inconsistency

Django Internals ORM
1

I accepted this ticket: #34949 (Fails to create unique constraints) – Django describing the behaviour inconsistency between Index and UniqueConstraint and wanted to elicit some discussion here.

tl;dr Index with include only ignores the option if not supported whereas UniqueConstraint with either include or nulls_distinct ignores the whole constraint if not supported.

Should this be a doc update or do we want to bring the behaviour inline?

Some thoughts:

  • UniqueConstraint has long-standing history of not creating the constraint if supplied option is not supported (eg deferrable). Changing behaviour to make only include or nulls_distinct options be ignore yet creating the constraint would make it internally inconsistent.
  • Is changing Index to behave like UniqueConstraint a better option?
  • Currently docs state with admonition “Deferrable unique constraints are ignored on MySQL, MariaDB, and SQLite as neither supports them.” yet no such admonition for include. If we go with doc update then I’d suggest doing that.
2

I think the two options need different treatment.

include is only an optimization, as the ticket’s OP noted. I don’t think a constraint should be skipped because it uses include when not supported.

On the other hand, nulls_distinct affects the constraint’s behaviour. Skipping creation there makes sense when not supported, in line with the current deferrable behaviour.

1 Like
3

Cheers your arguments make sense :+1:

Hm since you’re the only one responded and that I think I agree with you I’ll comment that we’ve reached consensus :sweat_smile:

4

But then we have a different question. How do we instruct Django to create Index(fields=[“a”], include=[“b”]) if supported but Index(fields=[“a”, “b”]) if not supported?