Changes between Initial Version and Version 2 of Ticket #25530


Ignore:
Timestamp:
10/08/15 13:46:13 (7 years ago)
Author:
Simon Philips
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #25530

    • Property Cc pdewacht@… added
  • Ticket #25530 – Description

    initial v2  
    8383The reason seems to be that any foreign key operations are added in SQL format to the `schema_editor.deferred_sql` list and are then executed after all other SQL commands. However, the third operation already renamed the column for that index to 'parent_id'.
    8484
    85 The deferred statements should follow any changes made during further operations. Or, if that's not possible, perhaps some sort of 'insert deferred statements now' operation could be added after each 'submigration' in the squashed migration?
     85The deferred statements should follow any changes made during further operations. Or, if that's not possible, perhaps some sort of 'insert deferred statements now' operation could be added after each 'submigration' in the squashed migration? In fact, that may even be desired, since the RunPython submigration may depend on the foreign key's behaviour/index for speed.
    8686
    8787Note that in this sample app it already crashes at the `CREATE INDEX` statement, but the statement after that is `ALTER TABLE "bug_child" ADD CONSTRAINT "bug_child_my_parent_3b5bc08e1603165f_fk_bug_parent_id" FOREIGN KEY ("my_parent") REFERENCES "bug_parent" ("id") DEFERRABLE INITIALLY DEFERRED`. I think the same issue might occur if `bug_parent(id)` would be renamed or removed.
Back to Top