Changes between Initial Version and Version 1 of Ticket #27746, comment 5
- Timestamp:
- Jan 24, 2017, 12:45:08 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #27746, comment 5
initial v1 1 It looks like this can't be done at the optimizer level as not all `RemoveField` operations can be fold into `DeleteModel` ones. For example, the `RemoveField` operations removing many-to-many fields cannot be optimized (as the schema editor's `delete_model` function doesn't deal with intermediary table deletions) but there's no way to figure out whether or not a `RemoveField` operation removes a many-to-many field or not .1 It looks like this can't be done at the optimizer level as not all `RemoveField` operations can be fold into `DeleteModel` ones. For example, the `RemoveField` operations removing many-to-many fields cannot be optimized (as the schema editor's `delete_model` function doesn't deal with intermediary table deletions) but there's no way to figure out whether or not a `RemoveField` operation removes a many-to-many field or not from its `reduce()` method context. 2 2 3 3 I believe the method that requires adjustments is the `MigrationAutodetector.generate_deleted_models()` one.