id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 23577,"Rename operations should rename indexes, constraints, sequences and triggers named after their former value",Chris Woytowitz,Victor Rocha,"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. Let's say I have a Django 1.7 app called `sample`: 1. Create a model `Bar`. 2. Create a model `Foo` with `bar = models.ForeignKey(Bar, blank=True, null=True)` 3. `makemigrations` (migration `0001`) 4. Rename `Foo` to `OldFoo`. 5. `makemigrations`, say yes to the rename prompt (migration `0002`) 6. Create new model `Foo`, which also has `bar = models.ForeignKey(Bar, blank=True, null=True)` 7. `makemigrations` (migration `0003`) 8. `migrate` When `migrate` hits `0003`, it throws this error: {{{django.db.utils.OperationalError: index sample_foo_4350f7d0 already exists}}} You may notice that `sqlmigrate sample 0001` and `sqlmigrate sample 0003` have the same line in both of them: {{{CREATE INDEX sample_foo_4350f7d0 ON ""sample_foo"" (""bar_id"");}}} 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. 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. The attached test case has a project `dj17test` in the state after having performed all of the above steps.",Bug,assigned,Migrations,dev,Normal,,,bugs@… aksheshdoshi@… emorley@… Ryan Hiebert Vadym Moshynskyi Thomas Riccardi Sardorbek Imomaliev Friedrich Delgado Daniel Hahler Bhuvnesh,Accepted,0,0,0,0,0,0