# Request for comments about a ticket: Index vs UniqueConstraint inconsistency
**URL:** https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097
**Category:** ORM
**Created:** [November 7, 2023, 6:11am UTC](https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097 "2023-11-07T06:11:17Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@shangxiao](https://forum.djangoproject.com/u/shangxiao)
#### Post date: [November 7, 2023, 6:11am UTC](https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097/1 "2023-11-07T06:11:17Z")
I accepted this ticket: [#34949 (Fails to create unique constraints) – Django](https://code.djangoproject.com/ticket/34949) 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.
---
### Author:  [@adamchainz](https://forum.djangoproject.com/u/adamchainz)
#### Post date: [November 14, 2023, 2:25pm UTC](https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097/2 "2023-11-14T14:25:21Z")
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.
---
### Author:  [@shangxiao](https://forum.djangoproject.com/u/shangxiao)
#### Post date: [November 16, 2023, 1:06pm UTC](https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097/3 "2023-11-16T13:06:19Z")
Cheers your arguments make sense 👍
Hm since you’re the only one responded and that I think I agree with you I’ll comment that we’ve reached consensus 😅
---
### Author:  [@rdaysky](https://forum.djangoproject.com/u/rdaysky)
#### Post date: [November 16, 2023, 2:52pm UTC](https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097/4 "2023-11-16T14:52:23Z")
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?
---
### Author:  [@felixxm](https://forum.djangoproject.com/u/felixxm)
#### Post date: [January 9, 2024, 7:35am UTC](https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097/5 "2024-01-09T07:35:25Z")
I don’t agree, users will get a clear message when using unsupported option in this case `models.W039`:
> _“models.W039: does not support unique constraints with non-key columns.”_
> _“A constraint won’t be created. Silence this warning if you don’t care about it.”_
It they want such constraint to be created by Django it’s enough for them to remove `include` from it’s declaration. I don’t think it’s better to pretend something is supported when it is not.
---
### Author:  [@adamchainz](https://forum.djangoproject.com/u/adamchainz)
#### Post date: [January 23, 2024, 10:47pm UTC](https://forum.djangoproject.com/t/request-for-comments-about-a-ticket-index-vs-uniqueconstraint-inconsistency/25097/6 "2024-01-23T22:47:43Z")
Ah, I was not aware of this warning. Yeah, it makes sense to skip the whole constraint using `include` in that case, then.