Django: Getting Started Transcripts
Chapter: DB Migrations
Lecture: Intro to migrations
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
In the previous chapter I showed you how to write your own Django management command.
0:05
In this chapter, I'm going to circle back to the database and the ORM. I'm gonna show you how Django handles when you make a change that affects
0:12
the underlying mapping of a table. You've seen the ORM models, each of which is abstracting away one or more table in the database.
0:21
You've also used the make migrations and migrate management commands. But what do these actually do? When you create or change a Django model,
0:30
it is creating a corresponding migration file that specifies what is to be changed in the database. The migrate command then invokes these changes.
0:40
So first I'll show you what these migration files look like, then go into more detail on how they get run and finally,
0:47
I'll even show you how to back out of them. If you need to, when you create a Django model,
0:53
you are creating the proxy to one or more tables in the database. That means when you change your model,
0:59
those same changes have to be applied to the database. Changes to the database may impact the data within the database.
1:06
So you have to be careful about how you manage the changes. For example, when you add an attribute to a model that is adding a column
1:14
in the database, what about data that's already in the table. If your column isn't allowed to be empty,
1:20
you're going to need to provide a default that fills it in for all the existing rows. Making changes to an existing column,
1:28
may require you to write scripts that explicitly deal with the change. Say for example, you had a name
1:33
column that you wanted to split into a first name and last name column. You're going to need to add a column and deal with the data splitting.
1:41
Django doesn't do all this for you, but can provide hooks to help. Likewise, removing a column with data in it can't really be undone.
1:50
You can put the column back, but unless you've explicitly stored the data from the column elsewhere, it's gone.
1:57
When you create a model or make a change to one, Django tracks this automatically for each change, a corresponding migration script gets created.
2:06
It is written in Python, but for the most part, it's just a data structure. The scripts are created in a directory named migrations inside of each app.
2:16
These scripts should be managed like any other code in your project. You do need to be a little careful here
2:22
if you're working with multiple developers on different branches. Let's say, you and I are both working on the same repo on our own branches.
2:29
If both of us touch the author model at the same time, a migration script will get created. That will have the same change number in it.
2:38
Although the repo would detect if I stomped on your code changes during the merge,
2:42
it won't detect this because each of us will get our own individual migration files.
2:48
So you need to make sure you properly coordinate model changes with your teammates. Let's learn by doing.