Squash all migrations before production deployment #376

Open
opened 2024-11-19 22:50:24 +00:00 by fricklerhandwerk · 2 comments
fricklerhandwerk commented 2024-11-19 22:50:24 +00:00 (Migrated from github.com)

We have accumulated ~40 migrations, some of which are fairly expensive. Squash them before deployment, otherwise we will have to run through them on every deployment.

We have accumulated ~40 migrations, some of which are fairly expensive. Squash them before deployment, otherwise we will have to run through them on every deployment.
Erethon commented 2025-04-29 09:55:04 +00:00 (Migrated from github.com)

Is this really necessary currently? Even though Django can squash migraton, the documentation mentions this wouldn't be a problem and if you ever want to do it it's usually when you have multiple hundreds of migrations (which we're not close to having).

Django doesn't re-run migrations on every deployment, it knows which migrations have run and only runs the new ones.

Is this really necessary currently? Even though Django can squash migraton, the [documentation](https://docs.djangoproject.com/en/5.2/topics/migrations/#squashing-migrations) mentions this wouldn't be a problem and if you ever want to do it it's usually when you have multiple hundreds of migrations (which we're not close to having). Django doesn't re-run migrations on every deployment, it knows which migrations have run and only runs the new ones.
fricklerhandwerk commented 2025-04-29 11:43:47 +00:00 (Migrated from github.com)

Django doesn't re-run migrations on every deployment, it knows which migrations have run and only runs the new ones.

That's true but it runs them on every test, because we start with a fresh deployment. That could be avoided by providing a database dump, but that opens a different can of worms: how and where to keep an up-to-date one?

> Django doesn't re-run migrations on every deployment, it knows which migrations have run and only runs the new ones. That's true but it runs them on every test, because we start with a fresh deployment. That could be avoided by providing a database dump, but that opens a different can of worms: how and where to keep an up-to-date one?
Sign in to join this conversation.
No description provided.