Welcome back, everyone, to this lecture on migrations.
In general, migrations are going to be the act of connecting changes in your Jingle project or jingle
application to the back end database.
And this includes things like adding new models in an application, adding an entirely new application
or even updating models of a new column or attribute in an application and models that profile that
already exists.
So you can think of this as any general changes that should be being kept track of in the database should
eventually get migrated from Python code to the back end SQL database.
Now, typically, you'll see these commands done through the managed pie file, so we're going to discuss
three key based commands for managing migrations, and those are the Make Migrations Command, Migrate
and then cycle migrate, which is kind of a specialty command that we won't use too often, but we will
show it in this particular lecture.
Let's actually begin with make migrations.
When you make migrations, you're going to run it with the managed top pie file, so something like
python, manage the pie, make migrations and the name of your application.
What make migrations does is it creates but does not actually run the set of instructions that will
apply changes to the database.
So, for example, if you run Make Migrations app, that's going to have a Python file, be created
and ready to be run in order to actually change that database.
Make migrations by itself does not actually perform any changes on the database, and you should note
that the default applications in Django, like admin or authentication, you can think of them as already
having had their skill make migrations code ready to go, and it's already been run.
However, they haven't actually been migrated yet, so the migrations are ready to go, but they haven't
been applied to the database, which is why you'll be able to see most tutorials as well as our own
code.
Well, we run right off the bat.
Something like Python managed that pie migrate and you saw that some migrations were being applied.
Those were the default ones.
But more on that later.
When you actually run, make migrations with your app, you can actually see the migration files being
created.
Those will be automatically located in your application and a new directory called migrations.
And then your very first one would be something like this.
Zero zero one underscore initial that pie and we'll explore this python file, but it contains a set
of instructions to go then and update your database.
And eventually these instructions are converted into sequel that can interact with a skill based database.
What's really nice about this is technically this Python file is very human, readable, and you can
edit it yourself.
Typically, we won't be doing that.
That's pretty advanced stuff.
And in general, you want to Django handle the heavy lifting and more complex tasks.
But in case you wanted to know, you could go in there.
Open it up.
Explore and edit the sexual python file before you end up migrating or running the migrations so it
can make migrations, makes the migration instructions, but doesn't actually run them to connect to
the database.
That is the migrates command.
So we run Python, manage that pie, migrate.
And this is going to run any existing migrations.
How does it find those migrations?
Well, we already know that when we create them through the Make Migrations command, that there's a
directory called migrations in the same way jingles able to find static or template files using directories
like static or templates.
It's also able to find migration instructions in the migrations directories, which is why, when you
run make migrations, those directories are created for you.
So that's a set of instructions that migrate then runs.
So this is actually running those Python files under the migration directory.
Now, the last commander I want to show you is Scott Migrates.
And this one's a little more complicated and we won't really use it that often.
But if you go and run in Python managed up high school migrate, then the name of your application and
the number associated with the specific migration python file.
This would actually show you what the school code looks like.
Keep in mind, it doesn't actually run any migration to your database.
It just spits out the set of SQL instructions in case you had maybe a backend SQL based developer or
database administrator who wanted to see what SQL code was actually being run to your database.
So it's really useful for things like debugging or interfacing with some sort of database admin.
Now again, you should note that we're not typically going to be reviewing files created under the migration's
directory or even be running Sequel Migrate, but we're going to be doing usually is just running,
make migrations and then migrate.
You can think of the very first migrate command we run as executing the default make migrations that
was already created for you upon creating the project, which is why when you create a new project,
you can actually run Python managed up high migrate and see things like the default authentication and
admin applications have their migrations being connected to the database, which is also why you see
upon running migrate the database actually being created, which is why again, we run that right off
the bat without actually creating a new application.
So what are the actual steps for migration?
I would recommend that you run your initial project migrant command that's going to create that database
for you and also make the migrations necessary for things like authentication and administration.
Then as your project grows larger, you're going to end up creating an app and creating models associated
with that app.
Then you have to remember to register the app and installed apps in settings that pie.
Having to register the app makes Django very modular, and it's very plug and play that way.
You can go ahead and grab this application and use it in a new project simply by registering it in that
new projects settings that pi file.
It also makes it easy to quickly disconnect an application from an existing project.
Once you've created the app, created the models and register the app, then you run.
Make migrations for that new app to get a set of instructions, and then you run migrate for those new
migrations.
OK, so let's explore these concepts based on the patient model class created in the previous lecture.
Recall that we've already run Python Managed Pie Migrate in order to run the migrations for the very
first set of default migrations ready to go like authentication and administration.
Now we're focused on the models that we ourselves have created in our new application.
Going to head to the coding app.
OK, here we are back inside our code editor recall that we've already ran the Python managed pie migrate
and note that it's applying migrations, all the things that are by default included in a single project
like administration authentication sessions, et cetera.
So it runs all those migrations, and you can also see this kind of zero zero one sort of initial Python
script naming scheme that are underneath directories migrations.
Now you don't really get to see those, but if you click here, you can see there's in it that PI file.
We're going to talk a lot more about being able to edit things default at a project level.
When we talk about the admin panel buffer right now, just go ahead and kind of ignore that and just
think, OK, there's some default applications that are already installed under settings that PI.
You can confirm that if you just go to the My Site settings, that PI essentially have all these installed
apps and we ran migrations for them.
But what about our own models on our own apps?
So we already have the patient model created, but we haven't actually made a set of instructions yet.
So we're going to do here because we're going to say Python.
Managed the pie, make migrations and then pointed to our application and our application name was office.
Now what's going to happen is it's going to try to figure out, OK, do you have an application called
office?
And then what are its models, etc.?
In order to make sure this actually works, you'll need to register the application as a configuration
within installed apps.
So before you run this, what you need to do is come to again settings, not pie, and check the installed
apps.
You'll notice our office app isn't actually there yet.
So what we're going to do is just come to app stop pie.
We've actually already done this one time before.
And note that by default, it's called office config.
So we're going to just use office config.
If you want, you can copy it, but come back to settings, not pie.
And then we're going to add that in, so we're going to say the following.
You can find our new installed app under office apps and then the office config.
Don't forget the comma here.
So this is the way you can then register this in settings that pi that way.
When to save those changes?
This python managed up to make migrations, knows what you're talking about when you actually say office.
So make sure you do this first under installed apps before you actually run this command.
If you get an error, run the command.
You should always be checking settings that pie to see if there's a simple fix there.
So we're going to enter here.
And it says, OK, I made some migrations for office, and by the way, they're located here office
migrations.
And here's an issue about PI and the general comment there is I created model patient.
So even the comments are automated for us, which is really nice.
Now, if we go to office under migrations, I can now see there's zero zero zero one underscore initialed
that pi.
And if you open this up, this is the Python file created by Django, which is eventually going to create
the actual sequel code in order to interact with the database.
Technically, you could mess around with this and edit things.
For example, you notice that it actually uses Django DB, but this time it's using a migrations class.
So a lot of this work has already been done for you, and Django has this migration class that automates
all of this.
You'll notice there's a bunch of variables that are important.
For example, initial equals true that just tells Django, by the way, this is the first migration
I'm going to do so initial.
It's true.
You can actually see that reflected in the naming schema with zero zero zero one score initialed that
PI.
And then it says, OK, I'm going to create this model.
The name of the model is patient, and then here are the fields.
And then it shows you the fields, and you'll notice by default, it actually creates a primary I.D.
key field, which if you're familiar, if Django or excuse me, familiar of sequel, that's a way to
identify each row as a unique ID row.
So you don't need to worry about that yourself when you create the models up here.
So even though you have first name, last name and age, when you actually create this, there is going
to be an initial ID index for that table.
Now maybe you're working with someone who works a lot with a sequel database, and they're not super
familiar of Django.
So they ask you, Hey, by the way, what is the actual SQL code that Django is running?
If you wanted to check that out?
You could do the following.
You could say Python managed our pie and then call the sequel Migrate Command, call your application
office and then point it to the number that you were concerned about for the actual migration file.
For example, the first one, we have zero zero zero one.
So it can say zero zero zero one enter.
And this will report back to you.
The school code that will be run again, you don't need to worry about this actually running in a school
code.
It's just saying, OK, when you run this Python file, that's going to automatically create this SQL
script for you.
So then if your SQL database admin is questioning, Hey, what's Django actually doing here?
You would just run this for whatever number of Python file migration you're interested in.
And then you could send that back to her or him and say, Hey, here is the SQL code that is being run.
OK, now, as I mentioned, just setting make migrations doesn't actually make the changes to the database
file when we're ready to do that.
We say Python, manage the pie, migrate.
That's going to look at all the migrations that haven't been run yet throughout all the applications,
and then I'll go ahead and run those.
So I hit Python, manage the pie and it says, OK, I'm looking at all the operations I need to perform.
I'm again checking admin authentication sessions and notice.
It's also checking office.
Now, it's not going to rerun the migrations that it already ran for Adam and authentication.
So then it reports back to you.
Well, the migrations that I haven't run yet that I'm going to run are the office ones and it says I'm
applying office zero zero one initial pilot, which is basically saying I ran this python file, which
in turn creates this SQL code, which in turn interacts with the database.
OK, so that's the very basics of migrations.
Again, you have the make migrations, which creates this python file set of instructions.
And then if you did want to check that skill code, you could say SQL migrate to check that out.
And if you are ready to actually run the migration, then you say Python managed API migrate.
OK, that's it.
I'll see you in the next lecture or begin to talk about database interaction.
How do I create, read, update and delete from this backend database through Python and Django?