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.
