The next model that we need to talk about is the Post model. But once again, this isn't just a straight up discussion. There are some actual things we need to consider. Our Post model is of course, going to represent individual posts, not just normal posts, but also replies because a reply is nothing more than a Post. The question then becomes how do we store those replies, or at least how do we relate a parent Post to

The question then becomes how do we store those replies, or at least how do we relate a parent Post to a reply Post? And the first thing that comes to my mind is something kind of like a pivot table to where we would have, you know, our Post model and then we would have Post replies so that we would have a parent_id, which would represent, you know, the, the parent Post. And then we would have a reply_id, which would refer to any Post that is a reply to the parent.

And then we would have a reply_id, which would refer to any Post that is a reply to the parent. And in my mind, it makes perfect sense to do that. But there are a couple of things that keep me from taking this approach. First, this kind of setup is for a manyToMany relationship where in a Reply is going to have just one parent. So it, it doesn't really fit into that manyToMany relationship for another. There isn't any extra metadata that we need to include.

to many relationship for another. There isn't any extra metadata that we need to include with a reply because a Reply is a Post, it therefore has all of the information that we need, such as who created it, the content of that post, when it was created, and all of that other stuff. And two, you know, this particular approach does require a little overhead from a database perspective because it requires another join. We have to join in another table.

a database perspective because it requires another join. We have to join in another table and that isn't really necessary. So I think the best approach in our case is to just have like a parent_id column. That way there's one less table that we have to manage and it makes it easier to find all of the necessary posts because, well, we don't have to join another table. And in theory this will be faster anyway because we would be able to index that single table, which

And in theory this will be faster anyway because we would be able to index that single table, which of course should be faster and it should make it easier to paginate the results if we need to do that. So let's start by making our model. We'll just call it Post. And we want the migration and the factory. And let's start by opening up the migration. So let's find that file and let's build it. The first thing that we need is the foreign

So let's find that file and let's build it. The first thing that we need is the foreign ID for the profile. So we'll have our profileId, which needs to be constrained, and if we delete the profile, we should delete the post as well. So cascade on delete, then let's go ahead and let's set up another foreign ID and we will call it parentId. Now in this case it needs to be nullable.

and we will call it parentId. Now in this case it needs to be nullable because not to every Post is going to be a reply, but we also need it to be constrained because the, the parent Post needs to exist before we attempt to create a reply for it. And then finally, we will cascade on delete as well. If we delete the parent Post, we should delete the replies as well. But then we just need, you know, the,

we should delete the replies as well. But then we just need, you know, the, the normal things like content, which is going to be a string. And we always need content. If we are going to create a Post, it should have content. And I think really that's all that we need to get started. I mean, we could talk about, you know, attaching media files to that, but then you know, we have to talk about uploading all of that.

to that, but then you know, we have to talk about uploading all of that. And for right now, I just want to keep things as simple as possible. So the foreign ID for the profile, the parent ID for the replies, and then the content are going to be fine, but let's set up some indexes. We'll set one up with the parent ID because that would be useful to be able to find the replies for a given post.

because that would be useful to be able to find the replies for a given Post. Let's also set up an index between profile ID and created at that way we would be able to find those posts a little bit faster. And I think that's gonna be great. So that now we need to open up the Profile model. We also need to open up the Post model because we need to set up the relationships there. And of course the first thing is going to be just posts.

because we need to set up the relationships there. And of course the first thing is going to be just posts. This will be a hasMany relationship, not a hasMany relationship to where we will simply return. This hasMany Post class and yeah, that'll be fine there. But then too, you know what if we need methods to retrieve, just, you know, the top level posts, ignoring all of the replies, and maybe I'm getting ahead of myself because you know, typically I tend

of the replies, and maybe I'm getting ahead of myself because you know, typically I tend to write code whenever I need it. But there are some cases, you know, thinking ahead of where we might just want to retrieve only the top level posts for a given profile. So we'll call it topLevelPosts. This two, we'll return a hasMany relationship so that we will just return.

This two, we'll return a hasMany relationship so that we will just return. This has many Post class, but then we need to be sure that the parentId is null because that ensures that it is a top level Post. So that's gonna give us that. And I think for now that's gonna be fine. You know, I can think of so many different things that we could include here, such as getting the Posts with replies or maybe just getting the latest Posts.

that we could include here, such as getting the posts with replies or maybe just getting the latest posts. I think those are all valid. We will probably need them. But I want to err on the side of, well, not necessarily caution, but I don't want to write any code that I don't necessarily need. So whenever we need those things, we will add them here. So now let's go to the Post model. And let's start with the protected fillable array.

So now let's go to the Post model. And let's start with the protected $fillable array. And we have several things here. We might need the parentId and really the profileId. So let's include that as well. Then we need the content and that should be fine as far as the $fillable array is concerned, so that then we can set up the relationship with the Profile, which is going to return a belongsTo relationship.

that then we can set up the relationship with the Profile, which is going to return a belongsTo relationship. So this belongs to Profile class, but you know, there's another relationship. If this is a reply, then we have a, a relationship with the parent. So we'll call this parent, which is a, belongsTo relationship to where we will return. This belongs to Post class. And then the column that we need to look at is parent_id.

This belongs to Post class. And then the column that we need to look at is parentId. But then we also need the replies. So we will have our replies, which returns a hasMany relationship, which we do need a use statement for. And this will return. This hasMany, once again, the class is Post class with the parentId column. And I think for now this is going to be fine.

with the parent ID column. And I think for now this is going to be fine. Once again, you know, there are so many methods that come to mind that we could implement. We could write a scope that would return just the top level posts, or we could write another scope that returns posts with replies. I mean, there's so many things, and I don't want to write a lot of code

I mean, there's so many things, and I don't want to write a lot of code that we don't necessarily need. If it turns out that we need them, then great, we can add them. But for now, let's just stick with what we have. Let's open up the PostFactory so that we can have our profile_id, which will be from our ProfileFactory. Then we need the parent_id, which we will just set to null. Then we need our content, which we will use Faker.

Then we need the parentId, which we will just set to null. Then we need our content, which we will use Faker to get some real text. And let's just say 200 characters. You know, we could put a limit on the content column itself. I don't necessarily want to do that, and maybe we should. And if we decide to do that later, then we can always come back and do that later. But then let's add another method so

we can always come back and do that later. But then let's add another method so that we can create some replies if we need to, and we'll just call it reply. But we will accept the parentPost and we will simply return this state and we want to change the parentId to the parentPost id. And then we will fake some content, which once again, we'll use Faker to generate some real text.

And then we will fake some content, which once again, we'll use Faker to generate some real text with 200 characters. And I think that that's going to be sufficient for our needs. We do need use statements for the Profile and the Post model, but I think that's gonna do it. So now the main models that we need to tackle are those for keeping track of likes, follows, and reposts, and we will talk about those in the next episode.

for keeping track of likes, follows, and reposts, and we will talk about those in the next episode.