Presumably more controversially I would also like to start a discussion around deprecating db_index and unique. Once removed it would reduce some logic in the schema generation code, which is currently quite complex because of these fields. It would also again give “one way to do it”. This will cause a lot of pain for users however, and there’s also some pain in the form of adding migrations for some of Django’s models. But I still think it’s worth having the conversation.
And if the answer is “no”, we should probably not say in the docs that “db_index may be deprecated in the future”. I personally think we should either do it or not, rather than give vague allusions that we may.
Fully agreed here. It’s either worth deprecating or it’s not. If we don’t want to actually deprecate it, maybe we still want to have a pointer to another way because we think it’s generally better.
Personally, I think we need to have a little more appetite for breaking changes as we find better ways to do things. For me personally I’d be fine with it here, but recognize that it can be annoying.
I understand the want/need to simplify the schema generation logic. (which, admittedly I didn’t look at before posting this)
On the other hand, from the other ORM’s (mostly non-python) I’m familiar with, having unique/index set on the column definition itself is very common. (And I personally find it convenient).
By an alternative, I am thinking of a get_constraints, get_indexes method or something similar that would build an iterable similar to Meta.indexes and Meta.constraints. Those method would aggregate the content of Meta and what (if anything) is found in the fields declaration? Or is this already what we are doing and is this where the simplification would lie?