Changes between Version 1 and Version 2 of Ticket #28862, comment 22
- Timestamp:
- Jul 13, 2018, 11:43:08 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28862, comment 22
v1 v2 3 3 As mentioned by Ramiro we'd need to have access to the ''previous'' `foo_together` value to determine whether or not the optimization can take place. This is a class of problem that also came up when working on #27768 where I had to disable an optimization from taking place because I didn't have the ''previous'' context of a `RemoveField`. 4 4 5 I guess I'd be possible to have newly generated operation embed a such a ''previous'' state to allow the optimization to take place but I figured out what I believe is a clever way of working around this disabled optimization. By implementing `CreateModel`/`AlterFooOperation` reduction most of the negative side effect during migration squashing where the optimizer wouldn't have been able to perform a complete reduction are gone because the former is able to reduce `RemoveField` operation .5 I guess I'd be possible to have newly generated operation embed a such a ''previous'' state to allow the optimization to take place but I figured out what I believe is a clever way of working around this disabled optimization. By implementing `CreateModel`/`AlterFooOperation` reduction most of the negative side effect during migration squashing where the optimizer wouldn't have been able to perform a complete reduction are gone because the former is able to reduce `RemoveField` operations to a new `CreateModel` operation. 6 6 7 7 All of these ideas are implemented in this [https://github.com/django/django/pull/10178 PR].