Changes between Initial Version and Version 2 of Ticket #25530
- Timestamp:
- Oct 8, 2015, 8:46:13 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #25530
- Property Cc added
-
Ticket #25530 – Description
initial v2 83 83 The 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'. 84 84 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? 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? In fact, that may even be desired, since the RunPython submigration may depend on the foreign key's behaviour/index for speed. 86 86 87 87 Note 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.