When writing applications for relational databases such as MySQL or PostgreSQL, there are two things to keep in mine:
- The first is the structure of the database itself. This includes things such as the tables, fields and relationships between tables.
- The second is how the objects in yout application map to data in your database. This involves writing code for mapping objects in our application to rows in the database and vica versa.
These two components need to work together, because if the structure of your database tables deviates from your objects, then you’ll get errors in your code.
Historically, this had to be done manually by writing SQL statements to create tables and their structures in your database. For example, if your application had to handle “products” you might write some SQL to create a table called “Product” with a number of fields used for storing the data.
Then you would write some code that made assumptions about this table (such as the name, fields, types, maximum character lengths, etc…). If you needed to make a change to the data (such as adding a new field), you would need to do this in both your app code and the database by writing SQL to modify the table structure.
The problem with this approach, is it gets difficult to manage quickly. As your site grows and you make more and more changes, the risk of errors grows which results in bugs, slow development, instabaility, data loss and so on…
Django has a brilliant solution to this problem, called the Object Relational Mapper (ORM).
The idea is that instead of managing your database manually, Django provides a set of tools which does it on your behalf.
These tools include the following:
- Database models to help you define the structure of your data in your code, and map them to objects in your database.
- The makemigrations command which auto-generates migration files that contain instructions for making changes to your database.
- The migrate command which run the instructions defined in your migrations.
This is where the migrate and makemigrations command comes in…
When you run makemigrations, Django will identify any changes you’ve made to your database models. If it sees a change, it will generate a migration file which contains the modifications required to make your database structure consistent with the model change.
Then, when you run the migrate command, it will look at these migrations and use them to make any changes required to your database.
So the difference between makemigrations and migrate is this:
- makemigrations auto generates migration files containing changes that need to be applied to the database, but doesn’t actually change anyhting in your database.
- migrate will make the actual modifications to your database, based on the migration files.