>> Once your migration is finished,
then you're going to have this db.sqlite3 file here locally.
Now out of the box, you can't work with this far
without like a specialist database client.
I'm going to show you a little trick actually just to
make life a little bit easier.
If you go to the extensions tab in VS code and search for SQLite,
you'll get this extension here called SQLite.
This is the third party one.
It's not one that's built into VS code,
but it's pretty useful for working with SQLite databases locally.
We're not going to edit the database,
we're just going to have a peak around so I can show you how
Django is actually working with the database behind the scenes.
Go ahead and install that.
Then once you've done it,
and go back to the project folder,
bring up your command palette and do SQLite open database.
It will prompt you and it should find
the one that's just being
created after running the migrate command.
If you click on that in the tasks tab,
you should see the SQLite Explorer,
inside that, you'll get the database that was created locally.
These are all the tables that Django made.
Most of them are internal to Django.
All the authorization tables,
as well as the record that Django keeps about
some additional things like
who's logged into the admin portal, stuff like that.
You generally don't have to worry about these tables.
You don't talk to them directly.
However, you should see this ready Cloud destination table,
which is the one that's being created to map
against the destination model that we described.
If we compare the two things, I guess so.
First of all, you will notice that it has this ID field,
I never asked it to create that.
It does it by default.
What it will do by default is it will give
each destination object a primary key,
so ID, and it will create that file automatically.
This one here is an integer and it's marked as a primary key.
You don't have to worry about incrementing
it, does that automatically.
But this is really useful when you start to
introduce relationships between different tables.
You'll also see the name field,
which is a Varchar and this is kept to a size limit of 50,
which we had in here, which is our max-length and
then we've also got our description which is a text-field.
The max-length is just on the server side,
it's not actually backed off onto the side to the database.
Let's say that we want to add an additional field to this as well.
Our destination here, we've got our name and our description,
I've also showed you some additional field types.
In there, we guess we had a slug field so that maybe we could refer
to that destination as a URL with a slug as well.
We could introduce slug here,
let's have a slug field and save that.
Now if we run make migrations,
it's going to because
an issue because I've introduced a new field called slug.
What it's saying is that if we add
that field and it has to have a record,
it doesn't know what to do with existing entries
in that database. It's saying what?
You've specified, a slug field needs to have an entry.
What am I supposed to do if they're
already entries in that database?
This question is really useful when you introduce fields which
are required and you already have data in your database.
You really need to think through how you
upgrade databases and add additional fields to it.
In this case, what I'm gong to do
is I'm going to specify a one-off default.
I'm just going to use
none as the option or she needs to be a string.
Let's put it in quotes.
Now we'll have two migration files,
the initial one and this additional
one where we've added a slug field.
As you build out your application,
you'll get more and more migrations in this folder.
When you initialize a new database,
it will run through the migrations
in sequence as they're numbered.
If we run that migration again and then click the
"Refresh" in SQLite and then scroll down,
you can now say we've got that slug field
that's been created in our database.
[MUSIC]