#28646: Migration calls "CREATE INDEX" when one already exists when 'unique' 
field
attribute is added (PostgreSQL)
-------------------------------------+-------------------------------------
     Reporter:  Hari - 何瑞理        |                    Owner:  (none)
         Type:  Bug                  |                   Status:  new
    Component:  Migrations           |                  Version:  1.11
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
  postgresql,migration,index         |
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Tomer Chachamu):

 * status:  assigned => new
 * owner:  Tomer Chachamu => (none)
 * has_patch:  0 => 1


Comment:

 I have added a reasonable PR. https://github.com/django/django/pull/9438

 The root cause is that {{{schema_editor.create_model}}} defers the
 creation of indexes, so at any time you can either have indexes on the
 database (can be found using {{{schema_editor._constraint_names}}}),
 deferred or not at all.
 
https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L300

 According to the comment they are deferred for SQLite, so one solution
 would be letting schema editors override the behaviour - removing it for
 non-sqlite, or just for postgres. I think it will become more difficult to
 reason about the schema editor in that case, and if done properly the
 deferred sql can also be an optimiser, removing redundant index creations
 and deletions.

 Every place that an index is added ought to check whether the index
 creation is already deferred, and remove the deferred one if so (in favour
 of an immediate one). Every place that an index is removed needs to check
 both deferred indexes and actual indexes.

 We can probably find more bugs by parameterising the schema and migration
 tests to try using separate schema_editors (which flushes deferred SQL to
 the database every step) or sharing schema_editors.

 Not all the lines added have a test backing them up but I think it's ready
 for somebody to have a look at and decide whether the approach is good.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/28646#comment:8>
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/066.7ed3a21f1c13a91b4f99377d3b5b9bbb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to