Changes between Version 27 and Version 28 of Ticket #23577

Oct 4, 2019, 9:56:28 AM (5 years ago)
Thomas Riccardi

Restore ticket description


  • Ticket #23577 – Description

    v27 v28  
     1This one's a bit of an edge case, but I ran into it trying to refactor some models on my moderately large work project.
     3Let's say I have a Django 1.7 app called `sample`:
     41. Create a model `Bar`.
     52. Create a model `Foo` with `bar = models.ForeignKey(Bar, blank=True, null=True)`
     63. `makemigrations` (migration `0001`)
     74. Rename `Foo` to `OldFoo`.
     85. `makemigrations`, say yes to the rename prompt (migration `0002`)
     96. Create new model `Foo`, which also has `bar = models.ForeignKey(Bar, blank=True, null=True)`
     107. `makemigrations` (migration `0003`)
     118. `migrate`
     13When `migrate` hits `0003`, it throws this error:
     14{{{django.db.utils.OperationalError: index sample_foo_4350f7d0 already exists}}}
     16You 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");}}}
     20In 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.
     22I 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.
     24The attached test case has a project `dj17test` in the state after having performed all of the above steps.
Back to Top