According to documentation, 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.
makemigrations are run through the following command
Python manage.py makemigrations
If the above commands says no changes detected, You can also do it for individual apps.
For example if you have 10 apps named a, b, c, d, e, f, g, h, i, j. You can run makemigrations individually for these apps.
Python manage.py makemigrations a
Python manage.py makemigrations b
Python manage.py makemigrations c
and so on.
Django app model makemigrations
makemigrations basically generates the SQL commands for preinstalled apps (which can be viewed in installed apps in settings.py) and your newly created apps’ model which you add in installed apps. It does not execute those commands in your database file. So tables are not created after makemigrations.
After applying makemigrations you can see those SQL commands with sqlmigrate which shows all the SQL commands which have been generated by makemigrations.
For example, if we make a model class-
from django.db import models class Person(models.Model): first_name = models.CharField(max_length = 30) last_name = models.CharField(max_length = 30) |
The corresponding sql command after using makemigrations will be
CREATE TABLE myapp_person ( "id" serial NOT NULL PRIMARY KEY, "first_name" varchar(30) NOT NULL, "last_name" varchar(30) NOT NULL );
and using above command, table will be created in the database when we use migrate.
