15đź‘Ť
The answer is “it depends”.
If you are working against a production DB, or some DB that can’t periodically blow away for whatever reason, then you absolutely want to keep around the migration files that you’ve applied to your DB. They should be checked into source control with the rest of your code.
Now, for a situation like yours, the easiest way to discard your 50 migrations would be to just blow away the db (and it’s 50 migrations) and start from scratch given your current models. It’s oftentimes a good idea to do this periodically as you evolve your models during development.
Its ok to blow away your models when you blow away your DB because syncdb will build a blank db using your current models. It’ll then optionally populate the db using any initial fixtures. Conceptually, there is no longer anything that you’ve migrated from at such a point, so you don’t need to keep around your old migrations for your old db. They are no longer relevant.
It’s not usually good to delete migration files that have been applied to your DB unless you are either 1) blowing away the DB altogether, or 2) reverting the migrations first.
You might also appreciate knowing that when you apply migrations to a db it’s also recording those migrations in a special table in the db itself. That’s why things go haywire when you just delete the migration files. They have to stay in sync with the migration table
2đź‘Ť
The answer is "Do not delete migration files".
To understand why we shouldn’t delete migration files, you need to understand how migration works in frameworks.
Migration files are the history of your database. One migration file is created based on the migration files created in the past. Deleting migration files means losing your history. This historical info is recorded in the django_migrations table in your database. if you delete migration files, you will get dependency errors. So Don't try to lose your history by deleting your migration files.
1đź‘Ť
If you want to keep your DB, but decrease the number of migration files, one option is squashing the migrations into one (or few, if complex dependencies) migration.
From the official documentation:
You are encouraged to make migrations freely and not worry about how many you have; the migration code is optimized to deal with hundreds at a time without much slowdown. However, eventually you will want to move back from having several hundred migrations to just a few, and that’s where squashing comes in.
Before squashing, you should be aware that “model interdependencies in Django can get very complex, and squashing may result in migrations that do not run“, and therefore manual work may be needed.
For detailed information about how to make the squashing, refer to the docs: https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations
- Django serialize multiple objects in one call
- Django: conditional expression
- Place to set SQLite PRAGMA option in Django project
- Django – how can I access the form field from inside a custom widget
1đź‘Ť
If models match database it is safe to delete migration files.
Currently, with Django 3 I can safely remove the migrations directory, then run python manage.py makemigrations myapp and python manage.py migrate. After that I have 0001_initial.py migration file and my production database is intact. This works when models already match database.
- 413 Payload Too Large on Django server
- Passing a variable in redirect in Django
- <django.db.models.fields.related.RelatedManager object at 0x7ff4e003d1d0> is not JSON serializable
1đź‘Ť
It probably isn’t a good idea (apparently), but if you are going to do it…
do not remove the __init__.py files.
In *nix:
cd [your project directory]
find . -path "*/migrations/[0-9][0-9][0-9][0-9]_*.py" -delete
find . -path "*/migrations/*.pyc" -delete
- Django: Custom User Model fields not appearing in Django admin
- Django – how to get user logged in (get_queryset in ListView)
- Django Celery Task Logging
- Show a successful message with Class Based Views
0đź‘Ť
In my opinion, it would be a bad idea. You can always roll back migrations if you make a mistake. Also, as migrations grow too large, you can also "squash" them. I learned about this from an article written by DoorDash.
You are encouraged to make migrations freely and not worry about how many you have; the migration code is optimized to deal with hundreds at a time without much slowdown. However, eventually you will want to move back from having several hundred migrations to just a few, and that’s where squashing comes in.
Squashing migrations: https://docs.djangoproject.com/en/3.2/topics/migrations/#squashing-migrations
DoorDash article: https://doordash.engineering/2017/05/15/tips-for-building-high-quality-django-apps-at-scale/
- Django translate model choices
- Pip install Django on python3.6
- Django Class Based Generic Views URL Variable Passing
- What is the correct way to deal with DB migration while using South, Django and Git?