Changes between Initial Version and Version 27 of Ticket #23577


Ignore:
Timestamp:
Oct 4, 2019, 7:34:15 AM (5 years ago)
Author:
clavay
Comment:

I tried this and it works : In the migration file I replace this : 

        migrations.AlterField(
            model_name='foo',
            name='variable',
            field=models.ForeignKey(null=True, on_delete=django.db.models.deletion.SET_NULL, to='app.Variable'),
        ),

with this : 

        migrations.RenameModel('Foo', 'FooNew'),
        migrations.AlterField(
            model_name='foonew',
            name='variable',
            field=models.ForeignKey(null=True, on_delete=django.db.models.deletion.SET_NULL, to='app.Variable'),
        ),
        migrations.RenameModel('FooNew', 'Foo'),

Is it a good solution ?

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #23577

    • Property Triage Stage Unreviewed → Accepted
    • Property Owner nobody removed
    • Property Cc bugs@… aksheshdoshi@… emorley@… Ryan Hiebert Vadym Moshynskyi Thomas Riccardi Sardorbek Imomaliev Friedrich Delgado added
    • Property Summary CREATE INDEX-related OperationalError on migrating renamed models with colliding field names → Rename operations should rename indexes, constraints, sequences and triggers named after their former value
    • Property Version 1.7 → master

  • Ticket #23577 – Description

    initial v27  
    1 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.
    2 
    3 Let's say I have a Django 1.7 app called `sample`:
    4 1. Create a model `Bar`.
    5 2. Create a model `Foo` with `bar = models.ForeignKey(Bar, blank=True, null=True)`
    6 3. `makemigrations` (migration `0001`)
    7 4. Rename `Foo` to `OldFoo`.
    8 5. `makemigrations`, say yes to the rename prompt (migration `0002`)
    9 6. Create new model `Foo`, which also has `bar = models.ForeignKey(Bar, blank=True, null=True)`
    10 7. `makemigrations` (migration `0003`)
    11 8. `migrate`
    12 
    13 When `migrate` hits `0003`, it throws this error:
    14 {{{django.db.utils.OperationalError: index sample_foo_4350f7d0 already exists}}}
    15 
    16 You 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");}}}
    18 
    19 
    20 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.
    21 
    22 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.
    23 
    24 The attached test case has a project `dj17test` in the state after having performed all of the above steps.
Back to Top