Fix restoring table indexes when rebuilding a table on SQLite.
Review Request #11082 — Created July 16, 2020 and submitted — Latest diff uploaded
Index handling for SQLite was a bit of a mess. When a table is rebuilt,
the old table gets dropped, losing any indexes. The official
instructions state that these should be rebuilt, but this wasn't always
happening. Some changes would prompt a rebuild, but not all.We now unconditionally rebuild indexes after a rebuild. Note that we do
not preserve any non-default indexes (so if a user has set up a custom
index, it will likely be lost), but this isn't a new problem.To make this happen, a bad default operation in the common code had to
be removed. We were always attempting to create an index if adding a
field that required one, which is fine for most databases, but it meant
that the SQLite code then had to work around this logic. That's part of
why other operations didn't end up creating indexes reliably.There was also a pretty brute-force operation that could be performed,
which was dropping a unique_together constraint. This was being done by
simply performing a table rebuild, which surely dropped that index, but
also dropped all the other ones. Older versions of Django needed this
due to utilizing SQLite-created auto-indexes, which could not be dropped
without a table rebuild, but it's not necessary on modern versions.These auto-indexes are still handled through a full table rebuild, but
all others are now dropped normally, removing any side-effects on a
modern setup.
Unit tests pass for all database on Django 1.6 through 2.0. Tested with
Python 2.7 and 3.8.