Migrations

We've already told Django which database we want to use and defined a model in our models.py file. Now, we want Django to actually create a table of courses with the fields defined in the Course model. We call this a migration, that is, the process by which Django generates or modifies a table (considering that we are working with relational databases) from a model.

To start working with migrations, first open the terminal and execute the following command:

python manage.py makemigrations myapp

The makemigrations command following the name of an application causes Django to generate the files necessary to make the relevant changes to the database based on what is defined in the model. In this case, those changes are creating the courses table. The output of the above command should be something like this:

Migrations for 'myapp':
  myapp\migrations\0001_initial.py
    - Create model Course

Each migration generates a file that is stored in the migrations directory within the application in question. Once created, you must apply the migration. The purpose of distinguishing the creation of a migration and its application (in the case of relational databases, the execution of the SQL query) is the ability to create migrations in a certain environment (for example, during development) and apply them in a different one (for example, the production environment.)

To apply pending migrations of the current project execute:

python manage.py migrate

The output of this command should look like this:

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, myapp, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying myapp.0001_initial... OK
  Applying sessions.0001_initial... OK

What has happened here is that pending migrations from other applications in our project have also been applied. The django-admin startproject command adds some applications by default, as we had mentioned before, as you see in myproject/settings.py:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'myapp.apps.MyappConfig'
]

We will see how these applications influence our project later. For now, open the db.sqlite3 file (you can use DB Browser for SQLite) to confirm that the table we had defined has been created:

Perfect! Note that, by default, the name of the generated table is appname_modelname. Since our application is myapp and our model is Course, the result is myapp_course. The remaining tables correspond to the other applications installed in the project.

You must do this process of creating migrations and applying them (via the makemigrations and migrate commands) every time you create or modify a model.