We have most of our models ready to go, at least theoretically. Now we just need to focus on Repost. A Repost is really nothing more than a normal Post. Originally I thought, you know, we would have another table to track Reposts, but no, that, that's not what we need. We aren't doing that for Replies because we have that self-referential set up with a parentId. We could just essentially do the same thing for the Reposts.

that self-referential set up with a parent_id. We could just essentially do the same thing for the reposts. Therefore, we have a unified table for all of our posts. And yeah, everything should be fine. So really what we want to do is take what we have for the parent_id and we're just gonna copy it and rename it to something like repost_of_id. I'm sure there's a better name, but for right now that that's what's going through my head. The idea being that this is a repost of,

that's what's going through my head. The Idea being that this is a repost of, and then the Idea of that post. So there we go. I mean that that's really all that we need to do as far as our migration is concerned. But we do need to go to our model because we need to add a method or, or do we, I mean, because yes, we have the parent set up, we have the replies set up so that we can get the replies.

because yes, we have the parent set up, we have the replies set up so that we can get the replies. Do we necessarily need to get the reposts? I think we do. So we're gonna do it here. And if this is a bad decision, we can always come back and change that. That's the beauty of writing software. Any bad decision we make, we can always go back and fix it. The problem is that bad decisions are sometimes really hard to realize that it is a bad decision

The problem is that bad decisions are sometimes really hard to realize that it is a bad decision until it's really too late to easily change things. But we're gonna be fine. So here we're gonna do essentially what we did with the replies to where we will return as many our model class is Post, but our foreign key is gonna be repost_id and that will get our reposts. I know that we're gonna need other things here,

and that will get our reposts. I know that we're gonna need other things here, but again, I want to refrain from writing just a bunch of code that I think I'll need. That's just a great way to add a lot of bloat. So when we find that we need something, we will write it. Until then, this is going to be sufficient. And now we just need to modify our factory. Now I know that we didn't implement the factories for like and follow and you know,

Now I know that we didn't implement the factories for like and follow and you know, after thinking about it, I don't really plan to do so because the functionality itself is, is very simple. All we really need to do is test to make sure that it works. And then when it comes time to implement that in our controllers, then we're gonna be fine. So as far as seeding the database, I'm more concerned about profiles, posts, things like that. And then we can just like and follow.

I'm more concerned about profiles, posts, things like that. And then we can just like and follow and, and things like that. If we decide to create factories later, that's easy enough to do. So. Okay, we need to add the repost_id field to our definition and the value is going to be null. But I also want to do kind of what we did with reply_to where we will have the repost and then we will have the quote_post.

where we will have the repost and then we will have the quote post. And the difference between the two is that a repost is just reposting it, a quote post is going to repost it and include some content. So that's the difference here. We're not gonna do parent post here, let's call it original post. So that here for reposting, all we are going to do is set the repost id equal to the original post id,

So that here for reposting, all we are going to do is set the repostId equal to the original post id, and our content is going to be null. Now, in the migration, did we set that content could be null? I'm not sure. Let's take a look. So let's open up the posts migration and null. It cannot be null. Well, we can easily do that. So content is null, which gives us the ability to just straight up repost. And then from there we have the quotePost,

to just straight up repost. And then from there we have the quote post, in which case it's going to do the same thing, set the repost of ID to the original post id, but then it's going to create some fake content and yeah, that's gonna get us exactly what we need. Well, we have all of our models, or at least I think we do. If we find that we need another model or another two models or whatever, then we can easily add them later on. For right now, I think we have everything that we need.

or whatever, then we can easily add them later on. For right now, I think we have everything that we need to start implementing our logic. But before we do that, I think we need to do a little light testing with our models.