Within our start cedar, we're already defining the specific roles and movie statuses that we want to work with. So we don't have factories for either one of those.

And as we've already learned in our movie factory, we can use states to specifically define which of those values we want to use for both our movie statuses.

And we can do the same for our rules whenever it comes time to it. So our relationship for our user roles and movie and movie statuses can use states to define what those values should be.

However, whenever it comes to our movie and its sinist for writer and director, we will want to specify the relationship inside of our factory for those.

So underneath our states here, let's go ahead and do dot relation just as we did with our user and profile. And once we hit our strings, we'll get our intellisense with our options here as defined on our model.

Again, we're gonna wanna skip over status and we can do director here. I'm gonna call back function that returns back the factory that should be used for our director, which will be our sinist factory.

And for Lucid to set this relationship, it's going to use the configuration that we've defined on our model for the specific relationship

to discern what column gets the value whenever it's creating the fake values. So whenever we create a movie factory with a director,

it will use our director relationship as we've defined it on the model to discern that the sinist factory's ID should be set on the director ID for our movie factory.

Meaning that if we scroll up here, we can get rid of our director and writer ID and instead just rely on the relationship to set those. And we're going to want to copy that, paste it in, and

do the same thing for our writer. Then we can jump over to our sinist factory and apply the inverse side there as well. So relation, and we have movies directed,

provide a callback that returns back our movie factory. And a relation for movies written, that provides back our movie factory there as well.

Now we need to actually provide in the fake information for both of these. So just as we're doing here with our profile, if we scroll down to where we're creating our movies, let's start with the simplistic ones here.

We can add on to these create mini calls a with director and with writer to create a sinist for both our director and

writer for each one of the three movies that will be generated with this call here. So let's go ahead and give that a copy and a paste, paste there and a paste there.

Now, alternatively, what we could do is where we're tapping into these actual movies that we're creating using our movie data is if we scroll up to where we're

creating our sinists, we have 10 being created here. We can plop those into a variable, so const sinist equals and provide them into our create movies call.

And for our create movies, we'll want this to be accepted in as sinists with a type of our sinist model and designate that as an array.

Now we can scroll down and on the specific movie row that we're tapping into here, we can do row.directorId equals, and

we can reach into our already created sinist array. So sinist there, and reach for a random index inside of this array

to randomly assign a director from our already created pool of sinists up here. So that we're not just randomly creating a bunch of directors and

writers per each of our movies being generated, but instead we have single sinist records bound to multiple movies as a director or writer.

So let's do math.floor here and then math.random, and let's multiply that random call by our sinist.length

to get back a random sinist out of the 10 that we've created here. And then we just want to grab that sinist's ID. Now, we're going to get a red squiggly because the object is possibly undefined.

We know that we're working with an already created array, and we're just grabbing a random index inside of that array. So we can assert that and get rid of the undefined possibility using an exclamation point there.

We'll copy this, paste it in, and let's do the exact same thing for our writer ID as well. Awesome, so whenever we actually run this, we'll have sinists that have been

a director or writer of multiple movies. In addition to those just written and directing one single movie. So let's hide our text editor back away, open back up our terminal, and

node.ace.migration.refresh-seed to get that applied inside of our database. Let's go ahead and clear that out, and

let's jump into our REPL session real quick to verify everything. Await, load models, let's do const movie equals await models,

movie, find or fail a movie with an ID of one, movie.serialize to see what we got, 310 the Yuma, okay.

Let's await movie load their director, and let's await movie load their writer. So now we can do movie director, serialize that so

that we just get back the data as well. And there's Clark Stroson with an ID of eight, which matches our director ID on our movie, awesome. Let's do the same thing with the writer.

So movie writer serialize there as well. And there's Diego with an ID of four, which matches our movie's writer ID. Awesome, let's take a look at Clark on the inverse side.

So let's do const Clark equals await models, sinist, find or fail, and he has an ID of eight.

So we'll find or fail an ID of eight, enter there. We'll do Clark.serialize, and we should see Clark Stroson there, which we do. Let's see, Clark was our director.

So we will await Clark.load movies directed, and then we should be able to do Clark.movies directed.

If we can already see from the preview that we're gonna get back an array of movies, let's map over those, movie.serialize, so we just get back the data objects.

Enter there, and there we go. We get back a number of different movies that Clark has directed.