8

I have an app that currently has 35 south migrations. These take a while to go through when setting up a new deployment (we create new deployments often), and the app is continually evolving--adding more migrations. Additionally, the migrations include some potentially complex data migrations and a few custom migrations that break SQLite3 (not a huge problem right now since everything is on Postgres, but its nice to be able to set up a quick test environment), and generally just more things that can go wrong.

All of our deployments and developers are up to date, and I'd like to clear out all of the app's migrations and create a single initial migration (0001) that captures the current state of the app, and then go forward with new migrations from there. I did this a few years ago with a different app, and it worked out nicely, but I've since forgotten what the process was and lost track of the blog post that explained how to do it. Can anyone break down this process for me?

B Robster
  • 40,605
  • 21
  • 89
  • 122

1 Answers1

13

I figured this out (wasn't too bad). To set up the migration reset, I do the following:

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

I commit the changes to the repository, and then for each deployment of the code elsewhere, run:

python manage.py migrate <app-name> 0001 --fake --delete-ghost-migrations

Make sure you don't add anything new between the time you last migrated everywhere else and you reset things or the new 0001 migration won't match up with the schema!

Caveats: See guettli's comment (and my responses)

B Robster
  • 40,605
  • 21
  • 89
  • 122
  • I see two problems with this solution. First: Changes of datamigrations are lost. This does not affect your live system, but new development systems you set up from scratch. Seconds: Imagine you have app2 which depends on a schema state/migration which was deleted. – guettli Dec 09 '13 at 10:06
  • Good points, @guettli! These scenarios often won't be applicable, but people need to understand them and make sure either they don't apply to your situation or you deal with them. – B Robster Dec 11 '13 at 22:40
  • As to #1: many data migrations are in fact migrations and won't be applicable for new deployments (since there's no records to migrate). However, as I assume you're addressing here, there are scenarios where datamigrations can be used to set up data (e.g., setting up permission groups), in which case they need to stick around. As to #2, in my answer, it is presumed that it is feasible to update every deployment to the latest schema before nuking, but this may not be possible for shared or open source apps or big teams. In this case, resetting migrations probably isn't worthwhile. – B Robster Dec 11 '13 at 22:44