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! baj ----------------- 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 https://groups.google.com/d/msgid/django-developers/b7d694aa-735f-429f-aae6-d0b948925d27%40googlegroups.com.
