Rename operations should rename indexes, constraints, sequences and triggers named after their former value

[Chris Woytowitz]

It is worth noting that if you use postgres instead, the error is django.db.utils.ProgrammingError: relation "sample_foo_4350f7d0" already exists.

[Simon Charette]

Haven't reproduced but the issue seems legit from the report.

I guess the RenameModel operation should also rename indexes generated from the original model name.

[Tom V]

I've found an associated case where a field with db_index=True, is renamed, and another db_indexed field created with the original's name.

Just discussed this with @andrewgodwin, I've agreed to write a test case for the field rename case, and then post about a solution on django-dev, with his preference being to make index names randomised.

[Tom V]

I've added a schema test case: ​https://github.com/tomviner/django/compare/ticket_23577_with_tests

This should currently fail on all backends except sqlite (which doesn't rename fields - it drop/creates the whole table). When this bug is fixed, it should pass for all backends, for that reason I haven't added any unittest.skip decorator.

Edit: link to tests updated.

[Tom V]

After ​a discussion on django-dev it makes sense to leave the resolution of this issue to ​Marc Tamlyn's Advanced indexes DEP, which he says will involve user specified/reproducible index names, as well as index renaming.

[ris]

Replying to tomviner:

I've found an associated case where a field with db_index=True, is renamed, and another db_indexed field created with the original's name.

FWIW I have worked around this in my migrations by doing two AlterFields, dropping & re-creating the index by doing db_index=False then db_index=True.

[skyjur]

This also happens when renaming a ManyToManyField and then adding a new ManyToManyField with the same name. I've opened ticket #25752 then @timgraham pointed out that it's duplicate of this one.

[Ian Clark]

I tried to migrate to a new model and bumped into this one. To fix, I made sure that I renamed my existing model to "old" first (e.g. Model->ModelOld), create the new model with the previous name (e.g. Model), migrate the data and then remove the old model. My previous strategy of creating the new table migrating the data and then renaming it broke due to the index issues.

[Luke Murphy]

Replying to ris:

Replying to tomviner:

I've found an associated case where a field with db_index=True, is renamed, and another db_indexed field created with the original's name.

FWIW I have worked around this in my migrations by doing two AlterFields, dropping & re-creating the index by doing db_index=False then db_index=True.

Confirmed. This worked for me also. I can use manage.py sqlmigrate <app> <migration> to see which indexes are giving me conflicts (should be the same as the error you get when you try to run migrate) and then used the db_index=False/True trick with AlterField.

[Simon Charette]

#24528 was a duplicate.

[Simon Charette]

#24715 was duplicate with a patch for the Oracle case where the sequence and triggers created for an AutoField are not renamed.

[Simon Charette]

This should also be the case for AlterField operations on both sides (e.g. foreign key constraint names are generated from their referenced table and column names).

[Martin Koistinen]

Until this is resolved, one can work-around this issue by doing something like:

        migrations.RunSQL(
            'ALTER INDEX myapp_mymodel_myfield_othermodel_id_0f4cfc54 rename TO myapp_mymodel_myfield_othermodel_legacy_id_0f4cfc54',
            'ALTER INDEX myapp_mymodel_myfield_othermodel_legacy_id_0f4cfc54 rename TO myapp_mymodel_myfield_othermodel_id_0f4cfc54',
        )

This sort of approach should work well for both FKs and M2Ms (example below), but it may make your migrations DB Backend specific =/

[Tim Graham]

I closed #28803 as a duplicate.

[jonathan-golorry]

I just ran into this issue with RenameField on ManyToMany relations. The (automatically generated) through table changes name, but the id_seq for it doesn't.

[Thomas Riccardi]

Some analysis (with postgresql backend):

• when creating a new field with index (such as a ForeignKey), django creates the column and the index
• when deleting a field, django only deletes the column: it lets postgresql delete all related index automatically
• when renaming a field, django only renames the column: it lets postgresql update all index references (and probably more), *but does not* rename the index

It seems django doesn't really track the index name, and it works great except for renames

=> when a new index has to be created for the old field name, the index name conflicts: this is this issue.

This reliance on field reference automatic update by the db seems to create a similar issue with index_together/unique_together:
field rename + index_together/unique_together alternation to update the field name results in no SQL except the RENAME COLUMN: the index/unique names are *not* updated.

The workaround from comment 17 (ticket:23577#comment:17) with a manual index rename may create issues when this ticket is fixed:
at that point django will probably assume the index name is the one it generates if it had to create the index, and the comment uses a different one (the hash_suffix_part is different)
=> for more rubustness/future compatibility I suggest to use the "proper" index name: manually create migrations to delete then re-create the field, and use ./manage.py sqlmigrate to get the created index name (it depends solely on table name and index fields name: see django/db/backends/base/schema.py:BaseDatabaseSchemaEditor._create_index_name)

[Thomas Riccardi]

To get the proper new index name:

from django.db import connection
schema_editor = connection.schema_editor()

def get_index_name(field):
    return schema_editor._create_index_name(field.model._meta.db_table, [field.attname])

get_index_name(ModelFoo.field_bar.field)

[clavay]

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 ?