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 Peter Thomassen	Accepted	0	0	0	0	0	0