On Wednesday, August 7, 2019 at 2:17:45 PM UTC-5, Adam Johnson wrote:
> Some questions: Have you looked into the migration framework internals? 
> Are there any comments around "replaces" that indicate this behaviour? And 
> is there maybe a way of hooking into the migration planner, or adding the 
> ability, to support your use case without relying on the current 
> bug-feature?

[Looks quick...]  Interesting!  
There are two subtle points in the source that show the author 
intentionally planned for this case, both in a method named 
"remove_replaced_nodes()" that, ahem, removes the replaced migration nodes 
from the dependency graph if the conditions are right for replacement.  The 
docstring for that method begins with the sentence "Remove each of the 
'replaced' nodes (when they exist)."  And within the main loop of that 
method, the code does a "pop" to remove the replaced node, deliberately not 
failing if that replaced node does not appear in the graph:
     replaced_node = self.node_map.pop(replaced_key, None)
     if replaced_node:

The purpose of this particular method is two-fold:  It removes the replaced 
node, yes, but just as importantly it rewires the dependencies to and of 
this replaced node.  Any children of the replaced node now become children 
of the replacement, and any parents that point at the replaced now become 
parents of the replacement.

So deliberate use of this approach does require careful understanding of 
the dependency tree (which really isn't a surprise).



You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to