On Monday, August 5, 2019 at 4:55:24 PM UTC-5, Barry Johnson wrote:
> [ TL;DR: A migration may use a “replaces” list pointing to migrations that 
> don’t actually exist.  This undocumented technique cleanly solves a 
> recurring difficult migration problem.  We seek consensus on whether this 
> should become a documented feature or that it is an unexpected side effect 
> subject to change in the future. ]

Earlier this week, I posted a question about an undocumented behavior in 
the migration system, wondering if it should be formally documented and 
supported.  The use case relates to migration of a database from one branch 
of a project to another when there were different migrations created in 
both branches.  I believe this is a use case that the migration system was 
not (and is not) intended to solve, yet it seems to be a real-world problem.

Summary of responses: 

After discussion, I think that -our- future approach will be more 
procedural:  We'll deliberately create an empty migration *just before* 
forking a parallel branch that may require migrations, and will eventually 
require migrating tenants from that branch back to our mainline code.  We 
will then use that empty migration as a placeholder, and if necessary 
create one or more migrations that will replace the empty step to handle 
any parallel schema changes.  It might be wise to document this practice as 
a suggestion for others faced with this use case.

We will still have a case where multiple migrations would each indicate 
that they replace one of those empty migrations, perhaps caused by multiple 
schema changes being applied to the "patch" fork.  We've seen that behavior 
create apparent duplicate entries in the django_migrations database table. 
 But the migration system loads that table into a set containing (app, 
name) tuples, so the duplicate entries aren't hurting anything at present.

Furthermore, there is nothing that deliberately ties the list of previously 
applied migrations (that set of (app, name) tuples) back to migrations that 
exist.  Entries in the table for migrations that no longer exist are a side 
effect of the current squashing logic.  They can eventually cause the 
django_migrations table to contain many more rows than are necessary; 
perhaps it may be useful to have a migration tool or operation that clears 
out those obsolete records.  Or, as Markus has suggested, it may be wise to 
have the squashing process clean up after itself by removing "replaced" 
entries instead of leaving them behind.

I'll work up a documentation change PR that people can review and accept, 
modify or throw away.

Thank you!

Barry Johnson

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