In our basics of CredList, we learned how we can delete records using a model instance, but this has changed a little bit

since we've now introduced a relationship into our user and role models, and we have data relying on that foreign key constraint. So let's dive into a Node.Ace REPL session

and let's await load models. And let's get an instance of our user since our user roles are the ones that have current relationship data bound by a foreign key.

So we'll await models user, find or fail our first user. Let's just do user.serialize to ensure that we've gotten back a user.

And there is Dolores Bosco. Okay, cool. Let's also await user load profile to verify that this user does have a profile.

So we should be able to do user profile serialize now to see their profile information. And there we go. So at this point, our user's profile is dependent upon the existence

of our user's record with an ID of one. And there's a foreign key constraint between our profile and our user records,

ensuring that any user ID that we have here must exist inside of our actual users table. So if we were to attempt to just await user delete

to delete our user out of the database, we're actually gonna get an error due to a violation of that foreign key constraint. And you can see right here on the detail section,

key ID of one is still referenced from the table profiles. So in order for us to delete our user with an ID of one, we need to delete the profile

dependent on that user ID of one as well. And that's true for any relationship that we have bound by a foreign key constraint.

So if we were to await user profile delete, this will delete our profile out of the database for a user with an ID of one. And that will then allow us to do user.delete

to delete our user with an ID of one. Now that's the manual approach to foreign key constraint relationship deletions. The alternative approach is to have that on delete cascade automatically for us,

so that whenever we actually delete out our user with an ID of one, their profile that's dependent on that user record that we're deleting will be deleted out as well. So let's jump into our code base and let's take a look at that approach.

So if we dive into our profile migration, because this is the migration where that user ID and his foreign key are being defined, we can chain onto the end of this columns declaration

and on delete call and specify the command for this to be a cascade. This will inform our database that anytime that we delete the user with an ID of one,

we're also going to want to delete this profile record that's dependent on that user with an ID of one as well. So let's give that a save. Let's hide our text editor back away.

Let's exit out of a REPL session, clear that out. Node, ACE, migration, refresh, hyphen, hyphen, seed to roll back, re-migrate and re-seed everything. We'll clear that out

and let's open our REPL session once more. Well, await, load models. Let's grab our instance of our user again.

Wait, models.user.findOrFailUserWithAnIDOfOne. Verify that we have a user here. Cool.

And then we'll hit the button, await user load profile. Let's verify that they have a profile here as well. There we go. Okay, so here we've just verified that we have a foreign key constraint

between our profile and our user records. So at this point, if we were to try and await user delete and we run that, we'd expect it to succeed. And there it did.

If we check out our user model, we'll see that isDeleted is set to true. And the reason why that succeeded this time is because we have that on delete cascade informing our database that we want to cascade

the deletion of a user into their profile as well. Now, one thing to note here is that if we take a look at our user profile, since we still have everything in memory,

we're gonna see that the isDeleted flag is set to false. The reason for this is because the cascade behavior is at the database level, not at the model level.

So at this point, the profile has actually been deleted, but our model instance is just out of date. So the behavior that we're seeing here is expected and correct.

We just didn't delete through this profile, so it doesn't actually know that it's deleted. So let's go ahead and try and refresh our profile. So we could do await userProfile.refresh

to try and grab a fresh instance out of our database. If we run that, we're gonna see that we get back model.refreshFailed because it was unable to look up a profile with an ID of one,

meaning essentially that it has been deleted and no longer exists in the database. We can confirm that by doing await modelsProfile

findByOrFail, we'll find by the user ID column with an ID of one. If we run that, we're gonna get an E, we're not found

exception because it could not find a profile with a user ID of one, furthermore confirming that the record has been deleted. Before we round out this lesson,

let's go ahead and apply this on delete cascade in a couple more places. So where this would be handy is between our cast movies and crew movies pivot tables.

Nope, that's our altered one. Let's take a look at the actual one that's defining the column for the relationship here. So if we delete a cynist or a movie out of the database,

we're no longer going to want our pivot table existence to be here because if the cynist no longer exists and the role in that movie no longer exists

and the vice versa, if the movie no longer exists then the cynist role no longer exists either. So it would make sense to go ahead and just cascade that deletion for both of these here. So add that in for both of those,

and we'll jump over to our crew movies and apply it here as well for both of them, just like so. Let's go ahead and refresh our database so that we have everything up to date. Exit out of a REPL session, clear that out,

node, base, migration, refresh, hyphen, hyphen, seed. Give that a run, and there we go.