Migrations are Django’s way of propagating changes you make to your models (adding a field, deleting a model, etc.) into your database schema. They’re designed to be mostly automatic, but you’ll need to know when to make migrations, when to run them, and the common problems you might run into. - Django Migration Docs
Creating a migration¶
- We recommend you to create migrations per app, where the changes are only about a single issue or feature.
# migration only for jobs app python manage.py makemigrations jobs
- Always create named migrations. You can name migrations by passing
python manage.py makemigrations jobs -n=execution_time_limit # or python manage.py makemigrations jobs --name=execution_time_limit
- While creating migrations on local environment, don’t forget to add development settings.
python manage.py makemigrations
The following is an example of a complete named migration for the
jobs app, wherein a execution time limit field is added to the
python manage.py makemigrations jobs --name=execution_time_limit
- Files create after running
makemigrationsshould be committed along with other files
- While creating a migration for your concerned change, it may happen that some other changes are also there in the migration file. Like adding a
Submissionmodel also brings in the change for
when_made_publicbeing added. In that case, open an new issue and clearly mention the issue over there. If possible fix the issue yourself, by opening a new branch and creating migrations only for the concerned part. The idea here is that a commit should only include its concerned migration changes and nothing else.