Opened 10 years ago
Last modified 3 months ago
#23577 assigned Bug
CREATE INDEX-related OperationalError on migrating renamed models with colliding field names — at Initial Version
Reported by: | Chris Woytowitz | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | bugs@…, aksheshdoshi@…, emorley@…, Ryan Hiebert, Vadym Moshynskyi, Thomas Riccardi, Sardorbek Imomaliev, Friedrich Delgado, Daniel Hahler, Bhuvnesh, Peter Thomassen | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description ¶
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
:
- Create a model
Bar
. - Create a model
Foo
withbar = models.ForeignKey(Bar, blank=True, null=True)
makemigrations
(migration0001
)- Rename
Foo
toOldFoo
. makemigrations
, say yes to the rename prompt (migration0002
)- Create new model
Foo
, which also hasbar = models.ForeignKey(Bar, blank=True, null=True)
makemigrations
(migration0003
)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.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.