[Django] Now that I know about make migrations and migrate, I've summarized them.

Introduction

Have you ever been curious about using Django? Did you run make migrations or migrate after making edits to models.py? When I first touched Django, I was running this command with brain death.

It's been about half a year since I started using Django for web application development, and what this command is doing I've come to understand it little by little, so I'd like to leave it in the article as a memorandum.

People who might find this article helpful

--People who have recently started using Django and are getting used to it --People who want to understand make migrations and migrate

Previous knowledge

About migration

-Django Official Document explains as follows:

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.

-Translation by DeepL

Migration is a Django way to reflect changes you make to your model (such as adding fields or removing models) into your database schema. It's designed to be mostly automatic, but you need to know when to do the migration, when to do it, and common problems.

In other words, what is migration?

--Mechanism for making changes to the database --Mechanism to reflect changes made to models.py in the database schema --Something like a database version control system (maybe this is the easiest for anyone using GitHub?)

About migration files

--File created based on models.py --Intermediate file to reflect the contents of models.py in the database --The first contents of models.py and the difference data file created by changingmodels.py based on it.

What happens with ./manage.py make migrations?

In conclusion, a ** migration file ** is created.

Person model

from django.db import models


class Person(models.Model):
    name = models.CharField(max_length=30)
    age = models.IntegerField()

When you run make migrations

$ ./ manage.py makemigrations

A ** migration file ** is created based on the Person model

from django.db import migrations, models


class Migration(migrations.Migration):

    initial = True

    dependencies = [
    ]

    operations = [
        migrations.CreateModel(
            name='Person',
            fields=[
                ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('name', models.CharField(max_length=30)),
                ('age', models.IntegerField()),
            ],
        ),
    ]

Now that the ** migration file ** for the Person model did not exist, a file was created with the filename 0001_initial.py. After that, the migration file will be updated based on this 0001_initial.py.

Now let's add a field called weight to the Person model and run make migrations again.

from django.db import models


class Person(models.Model):
    name = models.CharField(max_length=30)
    age = models.IntegerField()
    weight = models.IntegerField()

$ ./ manage.py makemigrations

from django.db import migrations, models
import django.utils.timezone


class Migration(migrations.Migration):

    dependencies = [
        ('sample_app', '0001_initial'),
    ]

    operations = [
        migrations.AddField(
            model_name='person',
            name='weight',
            field=models.IntegerField(default=django.utils.timezone.now),
            preserve_default=False,
        ),
    ]

This will create a new 0002_person_weight.py that depends on 0001_init.py.

This 0002_person_weight.py is an image in which the difference from 0001_init.py is recorded.

That is, running make migrations will leave any changes to the model in a file. However, just executing ** make migrations will not be reflected in the database. ** **

What happens with ./manage.py migrate?

Reflect the ** migration file ** created by make migrations in the database.

An image that makes changes to the database according to the migration file.

You can reflect a specific migration file with ./manage.py migrate app name migration name. If the application name and migration name are omitted, all unapplied migration files will be reflected in the database.

./manage.py migrate If this is the case, all unapplied migration files will be reflected in the database.

at the end

You may have noticed it, but it was my first post ... I think there are still many points that can be improved in the content and writing style of the article, but I would like to remember and improve while writing!

I enjoyed writing the article, so I think I'll post it regularly from now on.