-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression: index dropped in migration and not recreated #58
Comments
Doubtless there are more cases that should be tested, but these are the 3 specific ones that I've found to be broken and reported in issue ESSolutions#58 These tests fail on latest django-mssql-backend (e.g. v2.8.1) but passed on v2.4.2 before ESSolutions#24 went in.
Considering how to solve this, one approach would be to expand the condition under However before that we should ask: is it actually necessary for all indexes to be dropped in these 3 cases? If it can be avoided then it will save wasting time during migration of a large table. MS SQL Server seems to allow those 3 operations to occur while the index is there (it didn't explode in those cases using v2.4.2). @OskarPersson do you know what the reasons were for adding all these "delete index before doing X" in 2e60754? |
This issue still remains in the new Microsoft-supported fork of this project so I have filed it there 👆 |
Now fixed in microsoft/mssql-django#14 |
Problem
In the following cases (possibly more) any indexes on the column are dropped, but aren't recreated afterwards:
(a) when a column is made null-able (i.e. adding
null=True
)(b) when a column is renamed
(c) when a table is renamed
This is quite a major issue because it is silently leaving the database in the wrong state - the migration doesn't fail, but now certain columns with
db_index=True
won't actually have an index which could cause very slow queries.Cause
As far as I can see this is a triple-regression introduced by 2e60754 (for #24).
That commit added new calls to
_delete_indexes
in 2 places causing the first two cases listed above:and an explicit index deletion here before renaming a table causing the third case:
but in none of those cases is the index re-instated afterwards, even if the field still has
db_index=True
. Index restoration only happens in certain specific cases (e.g. type change / removal of nullability) which doesn't include the above 3 cases.Reproduction
See the 3 tests I added on this branch:
master...sparrowt:issue58-index-reinstatement
which fail due to the bugs described above, but pass if run on
django-mssql-backend
v2.4.2 (before #24)The text was updated successfully, but these errors were encountered: