I have some comments regarding 3. The idea, if I've understood your recount of the problem, is a good one. You want to be able to run a backwards-compatible migration (database works with app-state X and X+1), upgrade your application servers, and then run another migration that works with app-state X+1. The best example is adding a nullable column, incrementally upgrading your applications, then changing the nullable column into a non-nullable column.
I don't think that django migrations should try to understand the difference between compatible/destructive migration operations though. This is best handled (currently) by doing two individual deployments, with separate migrations. The first commit would have the addition of the nullable column -> deploy/migrate. The second commit would remove the null constraint -> deploy/migrate. I was thinking about support for applying a subset of migrations: ./manage.py migrate app -n 1 But then your model and the state of the migrations are out of sync. (Probably) much better to separate out the deployment into two discrete operations and code. Josh On Wednesday, 24 September 2014 08:54:28 UTC+10, Shai Berger wrote: > > Hi all, > > I gave a talk to a local user-group about the migrations in 1.7, and some > people in the audience raised things they would like to be able to do, and > are > not supported by the current framework; thought it would be nice to bring > them > here. > > Two issues were about handling migrations at the project level rather than > app > level: > > 1) Cross-app migrations. The act of moving a model from one app to another > should be a common-enough refactoring; especially for beginners, breaking > a > piece of an app out to a separate app is something a user is very likely > to > want. Current migrations, being app-oriented, make this possible, but a > little > awkward. > > 2) Roll back project to point in history. This is requested by people who > want > to work on feature branches (or any separate branches, each with its own > migrations). It is a bit of a hard problem I've run int myself, and I > suspect > it requires some integration with source-control systems to be done right. > The > solution I recommended (and used) was to keep separate databases for > separate > branches, but that is quite cumbersome in a large project. > > The third issue is an intriguing idea. It was presented as "keep more than > one > state of migration history in the database", but I think that a general > multiple-migration-history mechanism is neither required nor sufficient > for the > user's goal. What he wanted was: > > 3) Separate "destructive" migrations from "non-destructive" -- if I got it > right, "destructive" in the sense that "the old code can no longer work > with > the database after the migration". So, adding a nullable column, or a new > table, would generally be non-destructive. If you have several servers > running > on the same database, with this separation you can do a rolling upgrade -- > first make non-destructive changes, then upgrade the servers one by one, > and > only when they all have the new code, do the destructive migration. > > Your comments are welcome, > > Shai. > -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a2cff3eb-d04b-48c2-a915-8e2baffb090b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
