The most complex relationship is the many to many polymorphic relationship. But we already know, you know, the two individual pieces, the many to many relationship with the pivot table. And we also know the polymorphic relationship where, uh, essentially one table contains all of the relationship information between multiple types of other models. All we need to do is just combine those things together and then voila.

All we need to do is just combine those things together and then voila. So what we're gonna do is create a tag system, you know, so that we can tag users, or we can tag teams or tasks, you know, so like, uh, a user we can tag as contract so that we would know that that person is a contract employee, but we can also tag them as remote. Maybe they are both a contract employee and they remotely connect in and work.

Maybe they are both a contract employee and they remotely connect in and work. So we can define multiple tags for different things, and we don't have to create a single pivot table one for users and tags, one for tasks and tags, and one for teams and tags. It's just one pivot table that, well, it's polymorphic, it contains the relationship information for all of the other models. So let's start by making a model called tag.

for all of the other models. So let's start by making a model called tag. And then we want to create our pivot table. So let's make a migration called create tagable table. So it's going to be a little bit different than, you know, our, our typical many to many pivot table to where it's user tag, although that's in the wrong order. Tag user or tag team, we're just gonna have this tagable table that will, well,

Tag user or tag team, we're just gonna have this tagable table that will, well, it will store everything as you will see. So let's open up the create tag table migration so that we can add another column. Let's just call it name. And then that's gonna be good enough there so that then we can open up the create tagable migration. This is where all of the magic, well, not all of the magic, but this is where the database side of the magic happens.

This is where all of the magic, well, not all of the magic, but this is where the database side of the magic happens. So the first thing we want is the foreign ID of the tag, because we need to store that information here. So we'll have the tag id, but just like the other relationships, we want this as constrained because we want that referential integrity. And in this case we're gonna call cascade on delete, because if we delete a tag, we might as well delete everything

because if we delete a tag, we might as well delete everything that is tagged with that tag. You know what I mean? So there's that. But then we need to set up what's actually going to store the relationship. And we call that morphs method, and we're gonna call it simply tagable. So once again, this creates two columns. The first is going to be the idea of whatever entity

So once again, this creates two columns. The first is going to be the idea of whatever entity that we want to store this relationship with. And then we have the tagable type, which is the type of the model that we are setting up this relationship with. And, and there we go, that that's all that we have to do. So this is our pivot table. We're not gonna mess with any other pivot data, but we could include that if we wanted to. And then from there, we just need to set up our models.

but we could include that if we wanted to. And then from there, we just need to set up our models. So let's start with the user model. And we will have public function tags. And this is going to be a morph to many relationship to where we will simply return this morph to many. We want to use the tag as our model, and then the name tagable. And we just need to include this in every other model where we want this relationship.

And we just need to include this in every other model where we want this relationship. So that means inside of the tasks we'll just copy and paste. Uh, we do need a use statement, so don't forget to add that there. And then the team as well, if we wanted to include this with any of the other models, we could, but this is going to be just fine for us. So we have this side of the relationship set up. Now we need to create the inverse side,

So we have this side of the relationship set up. Now we need to create the inverse side, which is from the tag side. So let's open up our tag model and we want the fillable array. So let's go ahead and define that so that we can add the name in. And then we just need to define our inverse relationships, in which case we'll start with users. And it's going to return a morph to many relationship,

in which case we'll start with users. And it's going to return a morph to many relationship, but this is gonna be a little bit different. Instead of calling morph to many, we're gonna call morphed by many because this is setting up the inverse relationship there. So it's a slight little subtle difference, but it's an important difference in which case here we set up the relationship with the user and once again the name of Tagable.

up the relationship with the user and once again the name of Tagable. And then we just need to do the same thing for the other relationships such as the tasks. So we'll have tasks for the task model and then teams for the team model. And then when that is set up, we just need to see the database. So let's close everything else. Let's open up the database cer so

So let's close everything else. Let's open up the database cer so that we can create a couple of tags and then we can tag, you know, whatever it is that we want to tag. So let's create two tags. We'll start with a contractor tag. So we'll call tag create, and the name is going to be Simply Contractor. The, the beauty about this kind of design is

and the name is going to be Simply Contractor. The, the beauty about this kind of design is that we can create this contractor tag and we can assign it to whatever we need. It could be a user, it could be a team, it could be a department. I've never heard of a department fully of contract employees, but I mean you, you never know. We could do that. But then let's also create an urgent tag. This would be something that we would assign to, you know,

We could do that. But then let's also create an urgent tag. This would be something that we would assign to, you know, a task or, or anything else. So let's create that urgent tag so that then we have two tags that we can assign to something. We'll say that our user and we are going to attach the contractor tag. So we'll have contractor id. So let's do the same thing for the team so that both the first user

So let's do the same thing for the team so that both the first user and the first team are both considered contractors. But let's also get the first task. So let's just get that because we can easily just attach that urgent tag to it. So once again, we will use our tags method to get that relationship object so that we can attach the urgent tag to it.

that relationship object so that we can attach the urgent tag to it. So with that in place, we should be able to migrate fresh and seed so that now we just need to work with this data. And the beautiful thing is that there's really nothing new to learn as far as working with this data. Because we've worked with many to many. We've worked with polymorphic relationships. So that here with our user notes, we are including the notes, but we can go ahead

So that here with our user notes, we are including the notes, but we can go ahead and include the tags as well, so that whenever we view the outputs, we'll have not just the notes but the tags. But, uh, we do need to not just display the notes so that inside of the browser we can refresh. And sure enough, we still have the notes, but now we also have the tags. We can see that the contractor tag is assigned to the user,

but now we also have the tags. We can see that the contractor tag is assigned to the user, and we also get the pivot information. Now, we didn't add any pivot information, but you know, that information is still there. We can still access it if we needed to by using the pivot. And of course, if we wanted to approach this from the other side, from the side of the tags, we could do that. Let's add an endpoint for tags to

of the tags, we could do that. Let's add an endpoint for tags to where we will get the tag with. But in this case, uh, what do we do? We did users and teams, but we also have one of the tasks. And let's get the first, let's get all of them so that in the browser we can go to the tags endpoint and we will see a list of all of our tags. We are including the users as well as the teams.

and we will see a list of all of our tags. We are including the users as well as the teams. And notice how this is broken down. So our first tag with an ID of one is contractor. We assigned that tag to both the user with an ID of one as well as the team with the ID of one. So we have both of those there. Then we have the urgent tag, which we only assigned to the first task. So once again, I, I feel like I'm a broken record here,

to the first task. So once again, I, I feel like I'm a broken record here, but it's just a combination between the many to many relationship and the polymorphic relationships. It's the pivot table that allows us to store this polymorphic information, and we could use it to store pivot data. And we work with it just like the many to many relationship. So the many to many polymorphic relationship is the most complex.

So the many to many polymorphic relationship is the most complex. But, you know, after learning about the many to many and the other polymorphic relationships, it's, it's an easy concept. We still rely upon a pivot table to contain all of the relationship information. The only difference is that that pivot table has all of the relationship information for all of the models. In fact, at least in my opinion, the, the

of the relationship information for all of the models. In fact, at least in my opinion, the, the more difficult thing to remember is how to just set up the relationship. You have what are essentially the models that are tagable, like the user was tagable tasks were tagable teams were tagable. So you set up the tagable relationships using the morph to many method, but then you have the tag itself. The tag isn't tagable,

to many method, but then you have the tag itself. The tag isn't tagable, although that would be rather interesting. But instead it is morphed by the user, the task, and the team. In which case, whenever you set up that relationship, the relationship, you use the morphed by method. Again, it's a subtle little difference, but it is very important.

but it is very important.