#23577: Rename operations should rename indexes, constraints, sequences and
triggers named after their former value
---------------------------------+------------------------------------
     Reporter:  Chris Woytowitz  |                    Owner:  (none)
         Type:  Bug              |                   Status:  new
    Component:  Migrations       |                  Version:  master
     Severity:  Normal           |               Resolution:
     Keywords:                   |             Triage Stage:  Accepted
    Has patch:  0                |      Needs documentation:  0
  Needs tests:  0                |  Patch needs improvement:  0
Easy pickings:  0                |                    UI/UX:  0
---------------------------------+------------------------------------

Old description:



New 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`:
 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.

--

Comment (by Thomas Riccardi):

 Restore ticket description

-- 
Ticket URL: <https://code.djangoproject.com/ticket/23577#comment:28>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.eed1a3015da1ecb186ba4c0f1760baa4%40djangoproject.com.

Reply via email to