| | 1 | This one's a bit of an edge case, but I ran into it trying to refactor some models on my moderately large work project. |
| | 2 | |
| | 3 | Let's say I have a Django 1.7 app called `sample`: |
| | 4 | 1. Create a model `Bar`. |
| | 5 | 2. Create a model `Foo` with `bar = models.ForeignKey(Bar, blank=True, null=True)` |
| | 6 | 3. `makemigrations` (migration `0001`) |
| | 7 | 4. Rename `Foo` to `OldFoo`. |
| | 8 | 5. `makemigrations`, say yes to the rename prompt (migration `0002`) |
| | 9 | 6. Create new model `Foo`, which also has `bar = models.ForeignKey(Bar, blank=True, null=True)` |
| | 10 | 7. `makemigrations` (migration `0003`) |
| | 11 | 8. `migrate` |
| | 12 | |
| | 13 | When `migrate` hits `0003`, it throws this error: |
| | 14 | {{{django.db.utils.OperationalError: index sample_foo_4350f7d0 already exists}}} |
| | 15 | |
| | 16 | You may notice that `sqlmigrate sample 0001` and `sqlmigrate sample 0003` have the same line in both of them: |
| | 17 | {{{CREATE INDEX sample_foo_4350f7d0 ON "sample_foo" ("bar_id");}}} |
| | 18 | |
| | 19 | |
| | 20 | In my production case, I actually had no problems on servers, because South had created the index with a different name. When I renamed the models and added a field, the new index did not collide with the old one. However, our test suite started failing, because it would run the migrations from the ground up, exposing the above bug. |
| | 21 | |
| | 22 | I haven't decided on a workaround yet, but I thought I'd bring this to your attention. I might have to inject a migration that renames the index created in `0001`, or something to that effect. |
| | 23 | |
| | 24 | The attached test case has a project `dj17test` in the state after having performed all of the above steps. |