-
So far within our database schema, we've worked with everything except for our watchlist table. Our watchlist is bound to our users and our movies table,
-
and it's gonna keep track of movies an individual user is interested in watching. So our user ID and movie ID there keeps track of that relationship, and it will be a many to many relationship
-
because we can have many users wanting to watch many movies, and many movies with many users wanting to watch them. Apart from those two columns, we have our standard ID created at and updated at columns,
-
but we also have this watched at timestamp as well. And we're gonna use this to allow a user to keep track of whether or not they've watched a movie, and we're keeping that as a timestamp
-
just in case we might ever be interested in showing when exactly they watched it. So if this does not have a value, then it means that they didn't watch it, and if it does have a time within there, then it means that they watched it.
-
Now, unlike with our crew movie and cast movie tables where we didn't have a model for either one of those, and instead we worked directly through the many to many relationship between the movie and Cineasts table.
-
For our watch list, we are going to create a model for it, despite it being a many to many relationship. And then within the model itself, we'll define the relationship between the movies and the watch list,
-
and the watch list and the users individually without actually using that many to many type. This is a great approach whenever your pivot table is the focal point of the relationship,
-
where we can work directly with a watch list model rather than working through the many to many relationship on either side of that. And it also gives us a chance to show an alternative way
-
to define a many to many relationship as well. So let's do node ace make, and we'll create a model specifically for our watch list.
-
We'll also make a migration and a controller using hyphen MC there, run that. Okay, we can clear that out, jump into our text editor, and let's first dive into our database,
-
migrations, create watch list table migration. So everything by default here is a okay. In addition to our ID, we're gonna want a table integer for our user ID.
-
This will be unsigned references, our users.id to create that foreign key relationship between our watch list and our user.
-
This will be not nullable and on delete, we'll want to cascade the deletion into any of these records. We can go ahead and give this line a copy because we're gonna want that to be relatively similar
-
for our movie ID there as well. The only difference is going to be instead of users, it's going to be for our movies. Lastly, we have one additional timestamp,
-
our table timestamp watched. All right, that should do it for our migration. We can go ahead and jump back into our terminal and run node ace migration run there. Okey-doke, clear that out.
-
NPM run dev to go ahead and put our server backup, hide that away. And now let's jump into our watch list model and get the columns defined here as well. So we have an at column, declare.
-
We have our user ID of type number. We also have a column for our movie ID. That too is of type number. And then we have the watched at.
-
So we'll do at column. We'll get that as a date time if it exists. And then we'll declare that as watched at
-
as a type of date time or null since it is optional. Now, since we have a model specifically for this pivot table of our watch list,
-
instead of using the many to many relationship type in either our user or our movie model, instead we'll want to create this as a one to many relationship. Meaning within our watch list table,
-
this will be belongs to for both our user, declare user belongs to type of user. Scroll down a little bit further here and we'll do the exact same thing for our movie.
-
So belongs to movie, declare movie, belongs to type of movie. And that reads quickly there, of course, is just because we need to add an import type for belongs to.
-
So that's the relationship within our actual watch list model. What about within our user and movie model? Well, within our user, let's go ahead and scroll on down to where we have our relationships.
-
And rather than a has one or belongs to on this side, it's just gonna be a has many and we'll bind it directly to our watch list model. So we'll do at has many there
-
and point it to our watch list model. Declare watch lists as many type of watch list. Now watch lists may not be the most appropriate name
-
because in display sense, the user is really just gonna have one list, it's not multiple lists. So in that case, maybe we will just name this watch list rather than watch lists,
-
despite it being a has many relationship, just to stifle any potential confusion there. Then on our movie side, we're gonna do pretty much the exact same thing. So we'll just need to scroll
-
to where we have our relationships. We'll do these above the many to many in between our belongs to here. And actually we can go ahead and just copy this verbatim from our users
-
and go back into our movie, paste it in. And we just need to hit command dot there to get our quick fix options and add in our missing imports. So command dot there, command dot here.
-
There's also an add all missing imports. So I suppose we could go ahead and click that there as well. Give that a save. And now we have our relationships bound.
-
And despite our watch list being an actual pivot table between our users and movies, we've instead defined it as a one to many relationship between our movies and watch lists
-
and a one to many relationship between our users and watch lists, which gives us an alternative view at how we can go about many to many relationships within our application. Structurally, it's all still just the same thing.
-
It's just how we're treating it that's different.
