Now, we are going to create a migration to be able to continue with the previous entry, in which we saw the creation of a model in Django.
The first thing you might ask yourself would be...
What is a migration?
Generally speaking, since this same scheme is used by other modern frameworks such as Laravel, CodeIgniter 4 and Flask; we could see a migration as simply a schema that is going to be mapped in the database that we have configured, in which we generally indicate how a table is described.
Migrations are an incremental way that we have to update the schema or how the database is formed; With incremental I mean that we can add more migrations as we develop the project and they have a sequential order in which they are executed that is directly proportional to the order in which we create them.
Advantages of migration
Migrations have a huge advantage over the traditional scheme in which the definition of the database is a separate task; With migrations we can have full control over the tables that we have defined in the database and therefore we are creating another layer between the database and our project as such in which we have full control over the structure of the database. of data.
With migrations it is very easy to share your work scheme with other members of the project, since you can simply pass the file or migration so that your coworker or coworkers can use the same scheme as you; It is no longer necessary for everyone to create the database manually, but rather through our own framework.
So, now you know what migrations are for and their enormous advantage compared to other schemes; so let's go to our Django project to create the migrations.
Models and migrations
Remember once again to have configured your database, registered the application (or applications) that has the model(s) and created at least one model in said app; which we did previously; since, the migrations are generated from the definition that we have in the model.
Generate a migration
To create a migration in Django, nothing could be easier, we already have everything free when creating a project in Django; we simply have to execute the following command from your terminal, at the height of the application folders (inside the project folder):
python manage.py makemigrationsOr run the migrations per application:
python manage.py makemigrations firstAppIn either case, you'll see output like the following:
python manage.py makemigrations firstApp Migrations for 'firstApp': firstApp\migrations\0001_initial.py - Create model EmplyoeeIn which we already have the migration created; therefore, we have a folder called migrations inside the firstApp application and inside it, the corresponding migration.
Here you are free to customize certain aspects of it before Django translates this into SQL and then creates the table in the configured database; although it is generally NOT necessary to make any extra changes.
Run the above migration
To execute the previous migration we simply have to execute the following command:
python manage.py migrateAnd with this, a series of migrations will be executed, and not only yours, since, for each application that you have installed, even if it is by default in Django, they have migrations created and therefore they are ready to be mapped to the database with the above command:
Operations to perform: Apply all migrations: admin, auth, contenttypes, firstApp, 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 firstApp.0001_initial... OK Applying sessions.0001_initial... OKAnd with this, if we check in the database:
We have our table or tables created in case you had more than one migration or model defined.
Rerun migrations
You can run any of the above commands again:
python manage.py migrate
Operations to perform: Apply all migrations: admin, auth, contenttypes, firstApp, sessions Running migrations: No migrations to apply.But you will see that nothing happens, since Django detects that he no longer has to create a migration, since it was created and executed in the database and translated with the table in our database that we saw before; You may wonder how Django knows the table exists; Well, basically because of the other table that was created called:
Which basically keeps records of the migrations that are executed in our database; At this point you can create new applications and models, or define more models or change existing ones and at any point create and run migrations.
Conclusions
Migrations are a very powerful component that exist in these types of frameworks; They allow us to modify and add or alter the structure of the models so that we can later reflect these changes in new migrations and later in the database.
Remember the three steps to work migrations:
- Change the models (in models.py).
- Run the python manage.py makemigrations command to create migrations for those changes
- Run the python manage.py migrate command to apply those changes to the database.
Remember that each command does a specific operation and must follow the corresponding order so that everything works for you and you can see the changes reflected.
- Andrés Cruz
En español
Develop with Laravel, Django, Flask, CodeIgniter, HTML5, CSS3, MySQL, JavaScript, Vue, Android, iOS, Flutter