Avoid remaking tables for altering index_together and unique_together in sqlite3

[Akshesh Doshi]

Currently the alter_index_together/alter_unique_together methods of SchemaEditor drop and remake the whole table just to add/drop indexes but this doesn't seem to be required. The default methods defined in base.schema seem to do the job perfectly (in fact, more efficiently) to me.

I might be missing something here but no tests fail when I remove these methods from sqlite3.schema, so we are at least missing the tests to show why we might need to drop and re-create the whole table just to add an index (or a unique_together constraint).

[Claude Paroz]

Feel free to propose a pull request with the proposed changes.

[Akshesh Doshi]

PR: ​https://github.com/django/django/pull/6888

[Tim Graham]

I found that without sqlite3's DatabaseSchemaEditor.alter_unique_together() schema.tests.SchemaTests.test_unique_together failed on SQLite until 01ec127baec38b7f8281e6eca9def40f22c9e5ad.

I guess Markus copied the override_uniques pattern when he did a similar thing for override_indexes in d2202ec2d4d0477b682c6d0051f27ab4843ef89f.

The test added in 03900a02d5fd2efd6ae98bdb9974b78146f63040 fails when removing override_uniques=... in sqlite3/schema.py but starts passing after e24e9e0438cf3ba6c557558f68587d135a85e126 so it seems okay to remove that instance.

[Claude Paroz <claude@…>]

In 2960e3a3:

Fixed #26841 -- Avoid remake tables for altering togethers in sqlite3 (#6888)

alter_index_together and alter_unique_together no more use _remake_table method in sqlite3