3

As a project grows, migrations (both makemigrations and migrate) take longer and longer delaying quite a lot every deployment. Django let's you to squash them so you don't have a long list of migration files but still, the migrations take the same amount of time.

Then I tried the following:

  1. Remove all the migration files in my app
  2. Clean the django_migrations table in the DB
  3. Run makemigrations (to create the 0001_initial for my app)
  4. Run migrate --fake (to populate to django_migrations table)

Now the new migrations are really fast at the expense of losing the migration history.

So my question is, considering that this could be like a v1.0, and it is a standalone project which any other project depends on, What are the risks of doing this?

I have the feeling that it is something that should not be done, since I could't find any specific Django command to do it. South has a reset, but now django migrations only has the squash...

dnaranjo
  • 3,647
  • 3
  • 27
  • 41

1 Answers1

0

As long as all your installations was up to date when you deleted the migrations, there is no harm to delete old migrations. The single drawback is you can't go back in the database historic state easily once you deleted them, but except in case of old backups file, you should not have any use of it.

As I pointed out, just make sure everyone using your project is up to date before (or give them indications like the commit before the deletion so they can do the migrations before upgrading to HEAD if you are using a source version control).

If you are developping a third party app, it will make the installation more complicate (dealing with the --fake argument whether you are upgrading or installing...) but this is not your case.

Maxime Lorant
  • 34,607
  • 19
  • 87
  • 97