The one to many relationship is a lot like the one-to-one, which sounds kind of weird because they're obviously different. But a one-to-one has a relationship from a record in one table to a record in another table. And it's strictly that relationship. A one to many is the same record or another record, and a table has a relationship to multiple records. In another table, you can kind of think of it like a user having, you know, multiple blog posts

In another table, you can kind of think of it like a user having, you know, multiple blog posts or uh, multiple projects or multiple tasks. Let's use the tasks ideas. So the first thing we will want to do is set up our relationship. Now of course we have our user table, which Laravel generously gave us. We also have our user models, so let's open that up as well. And we still have the profile stuff, that's fine

We also have our user models, so let's open that up as well. And we still have the profile stuff, that's fine because we can have as many relationships as we need for a particular model. Just because we have a one-to-one relationship between the user and the profile doesn't mean that we can't have another relationship between user and, you know, something else in this case tasks. So what we need then is to create our tasks.

and, you know, something else in this case tasks. So what we need then is to create our tasks. So let's use Artisan to make a model called task. We want the migration. Let's also have a factory so that we can create some test data and let's open up the create task migration, because that is where, once again, we will create a relationship at the database level. Now, in this case, let's go ahead and let's start with our foreign id.

Now, in this case, let's go ahead and let's start with our foreign id. So we'll call the foreign ID method. And this is going to have a relationship to the user's table. So the foreign ID column name will be user id that's following the same convention that we used for the one-to-one relationship. And then from there we want some referential integrity. So we want this to be constrained.

And then from there we want some referential integrity. So we want this to be constrained. And you know, we could say that we want to cascade on delete, but this is something that we do need to think about because you know, we are talking about tasks and let's assume that we have a team of people, you know, that team can change. We could add people, we could remove people. And if we delete people, you know, do we necessarily want

We could add people, we could remove people. And if we delete people, you know, do we necessarily want to delete the tasks that were assigned to that person because you know, those tasks still have to be done. So when it comes to working with relationships, these are the kind of things that you will need to think about. Uh, and in this case, I would say that no, we don't want to cascade on delete because we could delete a user. That of course leaves us with orphaned task records,

to cascade on delete because we could delete a user. That of course leaves us with orphaned task records, but we could easily go in and assign those records to, or assign those tasks to someone else. So I think in this particular case, let's just call constraint. But something that we definitely don't want to do is call unique and then say User id, because we want this one to many relationship, which means that we are going to have multiple records inside

because we want this one to many relationship, which means that we are going to have multiple records inside of our tasks table. And many of those records are going to have the same foreign key is they're going to be assigned to the same user. So the user ID definitely does not need to be unique in this particular case. So we're gonna get rid of that, and we are just going to say

So we're gonna get rid of that, and we are just going to say that the user ID is going to be constrained. And then from there, we just need the, the rest of the normal stuff that we would have for a task like the title. And we'll have the status, the idea being that instead of just having a Boolean value, is it completed or is it not? This gives us much more flexibility so that we could use,

is it completed or is it not? This gives us much more flexibility so that we could use, you know, status codes if, is it completed, is it on hold, is it discarded? You know, those types of things. Just makes things a a little bit easier, more flexible to track in that way. So now let's go to our user model. And we essentially want to do the same thing with our profile, except that we have a different kind

And we essentially want to do the same thing with our profile, except that we have a different kind of relationship. So we'll call this relationship tasks. And this is going to return a has many relationship because a user will have many tasks, makes perfect sense. Whereas with the profile, a user has one profile, a user has many tasks, and the idea is going to be the same thing here to where we will return the has many method,

and the idea is going to be the same thing here to where we will return the has many method, and then we just specify the model for this relationship, which is our task model. So that is the relationship from the user to the tasks, but we also need to set up the inverse, in which case we want to open up the task model. And the first thing we want to do is set up the protected fillable. And what do we have? We had title and then status.

to do is set up the protected fillable. And what do we have? We had title and then status. So that'll work. Then we will have the relationship method, which in this case is going to be the user. And just like the profile where the profile belonged to a user, the task belongs to the user. So it's still a, a kind of parent child relationship, except that now a parent can have multiple children. We still kind of do the same thing. We return the belongs to method

We still kind of do the same thing. We return the belongs to method and then specify what this relationship is for the user model. And with that in place, you know, let's go to our factory. So our task factory here, and we'll set the title to be a faked sentence. So we'll use faker, we'll call sentence, and that's gonna be fine there. But for the status, you know, I guess we need to just

and that's gonna be fine there. But for the status, you know, I guess we need to just to define what the different status codes are going to be, but we will call random element. And let's see. So we'll have what C for complete, H for hold, let's say A for active. And if there were other statuses, then, then we could include those there. But that's gonna be it for our factory. So that now we just need to open up the database C,

But that's gonna be it for our factory. So that now we just need to open up the database C, we'll still create our users and our profiles. And then the inside of our closure here, uh, let's do something a little bit different. We will create our tasks. So we'll use our task model factory and let's say that we want 10 tasks per user. And we will make those tasks so that then we can use the tasks relationship.

And we will make those tasks so that then we can use the tasks relationship. And you know, we've talked about using the relationship to save a profile in the previous episode. Well now we can just save many of those tasks and that way it'll automatically assign those tasks to the given user. And everything should work there. Let's give it a shot. So we'll say PHP Artisan migrate fresh seeds so

So we'll say PHP Artisan migrate fresh seeds so that we can start everything over from scratch to get any errors. So we should be good there, but now let's use this inside of a route and a view. So let's go back to our routes and let's just work with our default route here. So of course we are fetching all of the users along with the profile information.

So of course we are fetching all of the users along with the profile information. But let's say that we also want to pull in the tasks because now that we have multiple relationships and we want to work with all of that relationship data all at the same time, it makes sense to go ahead and pull in both the profile and the tasks. Now granted, it really depends upon the circumstance. If we don't want to work with the profiles, then you know, we just omit the profiles.

If we don't want to work with the profiles, then you know, we just omit the profiles. But in this case, I plan to use both. So we will eagerly load the users, their profiles and their tasks, and then we will supply that to the welcome view. So let's open up the welcome view and let's make this a little bit easier to see at least inside of the browser. So I'm going to replace what we have here with this.

to see at least inside of the browser. So I'm going to replace what we have here with this. It's basically gonna be the same thing, except that now we are including the task information. So first of all, the profile is being used here for the handle. We don't really care about the user's bio in this particular case. But when it comes to the tasks, well, we still want to iterate over those tasks so that we can view them.

But when it comes to the tasks, well, we still want to iterate over those tasks so that we can view them. And of course, whenever we see this in the browser, we have the user's name and their handle, the tasks that they have, and each one is listed there. And if we take a look at telescope, we're going to see our query for the users, our query for the profiles for those users, and then the query for the tasks for those users.

for those users, and then the query for the tasks for those users. So even though we are including even more information to display the task information, because we eagerly loaded our data, we still have an efficient interaction with the database. So now that we are displaying all of the users, uh, some of their profile information and all of their tasks, let's take a step back and let's say that we want to display just, uh,

and all of their tasks, let's take a step back and let's say that we want to display just, uh, the active tasks for a given user. Now, I don't want to make any changes to what we have for the welcome view. So let's do this. Let's first of all take our welcome view. Let's copy and paste it. Let's rename it to simply list blade dot PHP. That way we still have that intact

Let's rename it to simply list blade dot PHP. That way we still have that intact and we can use that for displaying the list of users just like we did before. But let's also change the URL that is simply list, but let's copy this route and we want our default back. So, uh, we'll have our default to where we use the welcome view. And our welcome view will be where we display an individual user so that then

And our welcome view will be where we display an individual user so that then what we can do is get our user, which once again, let's just find the one with an idea of one. And we could pass this to our view and everything would work fine. But let's say that we want to customize this query, we want only the active tasks. So what we could do is use the tasks relationship for our user.

So what we could do is use the tasks relationship for our user. That's essentially going to limit our result set down to just the tasks for this user. And then we can customize the query to where the status is a for active. Then we will get those tasks so that now we can pass the user and the tasks that we want to display for that user. And of course, we need to modify our welcome view,

and the tasks that we want to display for that user. And of course, we need to modify our welcome view, but that's gonna be easy not to do. We'll get rid of this for each over the users. And then for the tasks, we'll just say for each tasks as task. So if we go back and uh, refresh here, there we go. We have our user information, including the profile information, but then we also have just the active tasks.

including the profile information, but then we also have just the active tasks. So we can use this relationship object to not only create and do other things, but we can customize the query, which is something that we talked about in the previous episode, but it didn't really make sense in the case of a one to one relationship in a one to many relationship. It does make sense. But what if we want to do essentially the same thing for,

It does make sense. But what if we want to do essentially the same thing for, you know, a list of users, but also for, you know, our relationships here for list, you know, because we are getting the users with the profile and the tasks. What if we wanted to customize the tasks relationship here? So that's once again, we would display just the active tasks.

So that's once again, we would display just the active tasks. Well, we can do that by using a function, which is going to give us access to the query builder, in which case we'll say query where the status is A, we will get all of that information, then we will pass that on to the view. So inside of the browser, we now need to go to slash list. And once again, we see our list of users, but now we have filtered the tasks to those

And once again, we see our list of users, but now we have filtered the tasks to those that are active. And if we wanted to see the completed, we would just need to change our query. And once again, if we wanted to see the ones that are on hold, we just change the status and the results, set changes. So the one to many relationship is very simple. It's not as simple as a one-to-one,

So the one to many relationship is very simple. It's not as simple as a one-to-one, but it is almost as simple. The primary difference is that of course, one record, a parent's record can have a relationship to multiple child records and another table. Well, in the next episode, we're gonna take this a step further and talk about the many to many relationship.

and talk about the many to many relationship.