Okay, so we have our user model defined and it's ready to go. But we also need to define models for the rest of the primary tables that we have within our database as well. So let's go ahead and do that next.

So we already created a movie model, so we can go ahead and start there. Whenever we created this movie model, we stripped out everything that would incorporate Lucid into this particular model. So let's go ahead and add that back.

First, where we're describing the class, we need to also extend that base model that we saw on our user model as well. You'll see a red squiggly show underneath our movie.

We can ignore that for right now and just move onward. So we already have some of the properties defined that match against columns inside of our database. So for these, let's go and add the column decorator back onto them.

We want to import that from Adonis Lucid ORM. We can give that a copy and paste it onto the rest of the properties here as well, just like so.

Now, we switched our abstract being required, so we'll get rid of that question mark there. And we're going to break everything here for a little bit because the all method and

the find method that we have defined on our model itself is conflicting with Lucid, because Lucid defines these as well. Hence the red squiggly that we saw on our movie class.

So we can get rid of those. And now our red squiggly is gone. We can also go ahead and get rid of the unused imports here as well. OK, cool. So there's quite a few columns here missing. We need to add those back in.

So first, we're going to need our ID. So we'll add column is primary, set that to true. And we'll go ahead and declare ID of type number. Then we have our status ID, writer ID, and director ID.

These will all be fairly similar. So we can just write one copy and paste and change the name of it. So declare status ID, and we'll set that to number here.

We'll give this a copy and paste it two times because we can switch one of these to our writer ID and the other one to our director ID.

Then we move into our title, slug, summary, abstract, which are all A-OK. And then we also have our poster URL as well.

So we'll column, declare, poster, URL as a string. And then we also have the created at and updated at to finish this off. So we have column dot date times.

So that Lucid knows that we want to use Luxon date times to ingest these columns in. We'll have our created at go ahead and auto create.

So we'll set auto create here to true, declare, created at, set that to a date time. And we'll import that from Luxon.

And then we can give this a copy, paste it down here and switch this to updated at. And then we also want to have this auto update as well. So auto update to true.

So for most of the strings inside of our application, bar one, that we'll take a look at here in a second, we made our strings default values, empty strings. And we made them not nullable.

For example, within our movie model, our poster URL is not nullable, meaning this value here will never be null. And the default value is just going to be an empty string.

So we're always going to have a poster URL value. We can still check and see whether or not it actually has a usable value by just doing a simple if check against it. But inside of our database, this value will never be null.

And if we jump into our create movie migration, we can verify that by scrolling down where

we have our table string, poster URL, not nullable defaulted to an empty string right there. OK, the one case that we didn't do that is on our users migration.

We have both our avatar URL and our full name here. Both of those are nullable. So within our model, we need to describe these columns as such.

So let's jump into our user model real quick and scroll down to those two columns. We have our full name here. Whenever we created our project, AdonisJS started this off as nullable. So we're A-OK there.

This is all that we need to do to describe a particular column as nullable. Just do string or null. So we need to do the same thing for our avatar URL here as well. So string or null.

And throughout our application, this will help make things type safe because TypeScript will now know that this value may or may not be null. And it will warn us about this if we try to use it in a not nullable way.

So all that just to say, if you have a nullable column inside of your database, make sure that you describe it as such inside of your model as well. It's going to make your application a little bit more easier to work with and safe as well.

But to my recollection, these are the only two columns that we have set throughout our application with nullable values because it's good to cover exactly how to approach that.

OK, so we have both our user and our movie models ready to go. It doesn't really matter what order we create our models in because it's just classes that are defined inside of our application.

It's not actually running anything at this point in time against our database. So ordering here does not matter like it does with migrations. So let's go ahead and pull the ACL up in our terminal and create a new model.

So we could do node, ace, make, model. And let's go ahead and start with our roles next. So let's create a roles model. We'll hit enter on that. And let's pause here for a second and talk about what just happened.

So we define the name as roles, but it created a model called role. This is another one of those naming conventions that AdonisJS uses.

So although our table names are going to be plural, so users, movies, roles, etc., the model that represents that table is going to be singular, as we see right here,

using the default naming convention, because oftentimes models represent a single row inside of that table.

So whenever we're working with a role model, it's going to be for a specific role. We can query from our roles table using the model.

But whenever we have an instance of that models class, that represents a singular role. So that's what's going on there. OK, so that we don't get lost with our progress. Let's go ahead and define our role model next.

Now, for the most part here, AdonisJS has already started us out ready to go. All we need to do is add one more column for our name. So at column here, declare name, that'll be a type string.

So our role is ready to go now. Let's go ahead and do movie statuses next. So let's jump back into our terminal, node is make model movie status. And there we go.

OK, let's jump into there and describe those columns. So this one's just going to be the same as our role. All we need to do is column, declare name string. Pretty simple. Jump back into our terminal.

And we really only have one more model here to describe because we can use relationships

to ignore almost completely our pivot or intermediary tables for our crew movies and cast movies. If I go ahead and pull our schema back in here to review, we have our roles taken care

of, our users taken care of. We're skipping watch lists completely for right now and saving that for later. We have our movie status and movies taken care of.

And we can use relationships to almost entirely ignore our crew movies as well as our cast movies. So that just leaves us with our Cines table next.

OK, pull that back away and let's do node is make model. Sin this word sounds so weird to say, but I don't even know if I'm saying it right. All right.

So let's go ahead and jump in here and describe these columns next. So for this one, we did our first name and last name separate. This will allow us to show how we can create a computed property to merge these both into one.

So we can declare first name is string and column declare last name is string. And then we also have a headshot URL as well.

So column declare headshot URL as string. OK, cool. So that should do it with the models that we have at present.

OK, so at this point in time, we're going to just completely ignore relationships and call our models done as they currently are, because relationships kind of complicate things quite a bit.

So we're going to walk through them one by one in a completely separate module. We're also going to see how we can query using each of the various relationship types that we have.

Before we get there, though, we need to have a solid understanding of models without the complications that relationships bring with them. and that's what we're going to be focusing on for the rest of this particular module.