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). Interesting. -- 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 https://groups.google.com/d/msgid/django-developers/b6e576b9-ebbd-4263-8dd3-ae6ec79ced54%40googlegroups.com.