Quantcast
Channel: Planet Python
Viewing all articles
Browse latest Browse all 22462

Mike C. Fletcher: Django Migration Migration Strategy

$
0
0

We embed Django in devices. There are 100s to 1000s of each device scattered around the world, each controlled by someone who may decide (for perfectly valid reasons) not to update one of those machines for years. Until now, we've used South migrations to allow a machine of any vintage to update to current release with a single update. We try to keep up with Django, but the South to Migrations migration is sticking a big old stick in that wheel. You see, the very first step in migrating from South to Migrations, is "Ensure all installs are fully up-to-date with their migrations"... duh, not going to happen.

The obvious solution would be to have South run all of the migrations up to the last one, then switch to Migrations... but South apparently can't run under Django 1.7+... so to run the last South migration you would need to have a Django 1.6 release available...

There seems to be a few major options:

  • package Django 1.6 + all modules needed for all South migrations install inside the firmware (i.e. in a parallel directory) (yuck)
  • introduce a "you must install firmware X before you can proceed to final firmware Y" restriction (yuck, but this seems by far the simplest)
  • write something that translates the automatic South migrations (by far the bulk of the migrations we have) into Migrations (hard?)
  • maintain parallel migrations until the very last machine is updated (likely many years)
  • do some git hackery where we checkout each hash where an auto-migration is created and try to run the Migration extractor (messy)

Anyone else approached this problem with a different solution?


Viewing all articles
Browse latest Browse all 22462

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>