#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
---------------------------------+------------------------------------

Comment (by 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)

-- 
Ticket URL: <https://code.djangoproject.com/ticket/23577#comment:23>
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 post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.59d5dca4e0a3e90d6d7e1e50879f312f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to