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


Ignore:
Timestamp:
Jul 13, 2018, 11:42:45 PM (6 years ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #28862, comment 22

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