Changes between Version 1 and Version 2 of Ticket #28862, comment 22


Ignore:
Timestamp:
07/13/2018 11:43:08 PM (2 years ago)
Author:
Simon Charette
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #28862, comment 22

    v1 v2  
    33As 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`.
    44
    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.
     5I 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.
    66
    77All of these ideas are implemented in this [https://github.com/django/django/pull/10178 PR].
Back to Top