Track unique indexes separately from normal indexes in the database state.

Review Request #12276 — Created May 13, 2022 and submitted — Latest diff uploaded

Information

Django Evolution
release-2.x

Reviewers

DatabaseState has 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
unique flag when generating an index name, meaning that two indexes
for the same field with different unique flags end up generating the
same name.

If applying an evolution that, say, turns off db_index and turns on
unique, we end up in a state where DatabaseState is aware of the
previous index from the db_index and 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.

Commits

Files