Our models and

their corresponding database tables are the backbone of any queries that we make.

They're what the ORM actually uses to get all the information that we ask for.

Over the past few Django courses, we've created and modified just a few models.

In this course, we're not going to introduce any new models, but

we do need to make a change or two to our course model.

Let's hop into Workspaces to see how our models are and

what changes we're going to make.

Okay, before we get to the meat of this course, I need to do a few things.

We need to add a new field to our course model, so that we can tie it to a teacher.

I wanna just use the user model that Django gave us,

there's no reason to reinvent that particular wheel just yet.

So let's go to our models inside of courses.

All right, so first we need to import the user model,

Django has a module named contrib.

So from django.contrib and inside contrib, there is a lot of useful,

but not required features.

It's where they all live, auth is one of those features.

So our import is from django.contrib.auth.models import User.

It's a pretty handy import to memorize,

there's a good chance that you'll use it in most of your projects.

Okay, so now we need to add the foreign key to our model.

So right down here, we're gonna do teacher = models.ForeignKey,

and that's going to go to User.

All righty, so since we've added something to our model, we need to do a migration.

So let cd into learning_site,

and then manage.py makemigrations courses.

And so you can see here that we're adding those non-nullable field teacher to

the course without a default, and we can't do that, we had to provide something.

So I know I have one user in here, which is me, and I'm the teacher for

all the courses that are currently in there, so I'm just gonna do one, and

I'm gonna enter in 1.

Now before we run this migration though, I wanna change one more thing.

I wanna add a character field into the course model, and

this is gonna hold on to what the subject of the course is.

So let's just say subject = models.Charfield,

default is a blank string, and the max length is 100.

Now there's a really good chance, like 99 point and

then as many 9s as you wanna type, that if I was doing this for

an actual commercial product or an actual project I was building,

I would have another model here that represents the subject.

Or I'd have some sort of taxonomy system, so

I could have multiple subjects, whatever.

For what we're doing here though, both of those are a little bit overkill.

And so I'm not gonna do them, but you should definitely feel free to try and

do those changes yourself.

So I wanna forcefy the default because just like with the teacher,

I have to have a value to put into our existing ones.

And yeah, I think we're good.

Let's go ahead and make one more migration.

And then let's run our migrations,

manage.py migrate courses.

All right, so our migrations have been made, and

we're ready to assign courses the teachers and subjects.

I don't wanna do all that on camera though, and

I don't wanna make you do it yourself.

So I've actually included a json file right here, fixtures.json,

that has all of the data already in it.

It's called a fixture file because it has fixed data that's going to get imported,

and so I wanna just show you how to use this.

I mean, it's full of json data, and

every item in here relates to a single database row.

There's a fields key here, and inside of each of these is the column and the value.

And then at the end of that where, there it is, model,

we have the app and model that it belongs to.

Django will read all of this, and it can create objects for

us based on what's inside of here.

It's a good way to set up starter data, that's really about it though.

You don't wanna use this for migrating from one database to another,

unless you're really, really careful.

All right, so let's go ahead and

load this with the appropriately named loaddata command.

Loaddata, and it's fixtures.json.

Cool, so it installed 89 objects from our one fixture.

Wow, that was a pretty quick review of our models, and

that fixture data is there waiting for you if you want to use it.

The database in the workspace should already have the data loaded though.

If you wanna make your own fixtures, you can use the dump data management command.

I'll put a link to docs about it in the teacher's notes.

Take a little break, and when you come back,

we'll talk about a really handy tool for evaluating your Django code.