Track unique indexes separately from normal indexes in the database state.
Review Request #12276 — Created May 13, 2022 and submitted
DatabaseStatehas previously tracked indexes and unique indexes
together in a single dictionary. If there were normal and unique indexes
with the same name, they'd conflict.
While it makes sense for them to conflict, this actually poses an issue
on Django 1.6, at least in unit tests. Django 1.6 doesn't consider the
uniqueflag when generating an index name, meaning that two indexes
for the same field with different
uniqueflags end up generating the
If applying an evolution that, say, turns off
db_indexand turns on
unique, we end up in a state where
DatabaseStateis aware of the
previous index from the
db_indexand returns it when looking to see if
there's a unique index present. The query we have is really asking "is
there a unique index for <columns>" and, if no, adding the unique index
for tracking. Since both used the same names, these lookups failed.
Django 1.7 and higher use different naming for unique indexes, so the
problem doesn't exist there. While ideally we'd just override the index
name generation for 1.6, we do need to be compliant with Django 1.6's
built-in logic or other things will fail. So separating out this state
is the cleanest (and hopefully safest) way of ensuring we can look up
and apply the correct state.
All unit tests pass for all versions of Django.