Okay, if we take a look at our database so far, note that we already have six tables in place. Now most of these are meta tables that Laravel creates to track various parts and aspects of the framework. The one that we're interested in is the users table, the actual real table that has a backing Eloquent model. And of course, every Laravel project ships with that users table because almost every project will need to manage users, including our forum. So here's the User model that's backing this, and that allows us to start thinking about what other models we'll need inside our forum application. So a User can create posts on the forum, which means we need a Post model, and a User can also comment on created posts, so we'll need a Comment model as well. We can create all of the models and data we need from the artisan console, so let's do that now. Now throughout this

on created posts, so we'll need a Comment model as well. We can create all of the models and data we need from the artisan console, so let's do that now. Now throughout this series you're going to see me use the A alias, that's a custom terminal alias that I've set up, and it's equivalent to php artisan. So whenever you see that, don't get flustered, that's all it's doing. If you type php artisan, then it will work exactly as expected. However, I would recommend setting up an alias because it saves you a lot of time in the long run. Okay, let's go ahead and ask artisan to make us a new model, and of course it will ask us what we want to call this model. We'll call it a Post, the singular form of the table name. Now what do we actually want along with this model? Well, we'll want to be able to create tests for it, so I'm going to ask for a factory, though we won't focus on that in

name. Now what do we actually want along with this model? Well, we'll want to be able to create tests for it, so I'm going to ask for a factory, though we won't focus on that in this particular episode, we'll come to that in just a moment. We want a migration so that we can define the columns. What else can we have? We could have a policy, a controller. Let's have a resource controller so that we can start filling out the index for posts down the line, and we can come back to policies and form requests and all the rest of it at a later date. That'll do for now. So I'll hit enter, and let's look at what's actually being created there. So here is our Post model, and it's very basic. It says it has a factory, and it extends the base model. Inside database/migrations, we have a new migration, and you can see this is the post table migration that the model is backing. We'll fill this out.

and it extends the base model. Inside database migrations, we have a new migration, and you can see this is the post table migration that the model is backing. We'll fill this out in just a moment. We should also have under factories a new PostFactory. So they are the three files that were created. Oh, we created a controller as well, right? So app/Http/Controllers. Here is the PostController, and because it's a resource controller, we should have create, destroy, edit, index, show, store, and update. So we'll get to using those various methods in just a moment, but it's so nice that Laravel will fill all of that out for you. You don't have to manually go and create those methods in a controller as long as you select it to be created when you make the model. Okay, let's jump into the migration, and let's focus on what columns we're interested in on a posts table. So for

as long as you select it to be created when you make the model. Okay, let's jump into the migration, and let's focus on what columns we're interested in on a posts table. So for example, a post is probably going to have a title. What is the post actually about? We also want the body, which is going to be defined by a longText so that it can be much longer than, say, 255 characters. So there's the longText of the body. Timestamps will give us the created_at and updated_at fields, which are absolutely fine. Obviously, a User creates a post, so we'll need to tie the user table to the posts table. I'll do that at the top. I like to group all of my IDs together, all of my standard columns together, and then all of my date columns together at the bottom. So this is just how I like to work, but you probably have your own paradigms. I'm going to use the foreignId for method,

and then all of my date columns together at the bottom. So this is just how I like to work, but you probably have your own paradigms. I'm going to use the foreignIdFor method, which allows us to use the fully qualified class name of a model rather than having to use the table name, which might change and isn't quite as strict, isn't quite as locked down. So foreignIdFor, and obviously it's a foreign ID for the User model. And we can say that this is constrained in order to make sure that our database self-manages when a User is deleted. So here we come back to that thought from earlier of what happens when a User deletes their account? What happens to all of their posts? Are all of their posts also deleted? I don't want that to happen by mistake. I want to be absolutely sure that that is built into our application logic rather than our database logic so that we can change.

also deleted? I don't want that to happen by mistake. I want to be absolutely sure that that is built into our application logic rather than our database logic so that we can change how that works on the fly. So I'm actually going to say restrict on delete, which will cause a database exception if we attempt to delete a User who has posts. So I think for now this is all we need for posts. We can come back later and we can obviously expand on this in future episodes as and when we need more columns. But hopefully if we run back to the terminal and I run php artisan migrate, yeah, it's created that posts table for us. Let's jump into our database, refresh. Here is the posts table. And sure enough, all of those columns are there as expected. So that is posts taken care of. Let's focus on comments. As before, we can run php artisan make:model. This is going to be a Comment.

all of those columns are there as expected. So that is posts taken care of. Let's focus on comments. As before, we can run php artisan make:model Comment. This is going to be a Comment. Again, let's have a factory. We'll come to that in the next episode. And we'll have a migration, a resource controller. I don't know about the resource controller in this case because we're never going to show just an index of comments. The comments are always nested under posts. So I'm actually not going to choose a resource controller. That'll do. So we have the Comment model class, we have the factory and we have the migration. Let's jump into the migration for comments. And again, we have a basic table called comments where we have the ID and the created_at and updated_at timestamps. Let's handle our foreign keys first. So table foreignId for, and of course a User creates a Comment. So it's a foreign

have the ID and the created_at and updated_at timestamps. Let's handle our foreign keys first. So table, foreign ID for, and of course a User creates a Comment. So it's a foreign ID for the User class and we'll call constrained again and let's restrict on delete. In other words, we're going to handle the deletion of a User's Comments in application code. And if we forget to do that, well, an exception should be thrown rather than the database taking control and taking hold of it. Next, let's think about the foreign ID for a Post. So a Comment belongs to a Post. Now you could get into a whole whirlwind of worry at this point thinking, well, actually you could comment on a Comment and that would be a polymorphic relationship, right? Because a Comment would have to be able to be linked to either a Post or another Comment. Yes, you could get into that complexity now, but I beg you, please

relationship, right? Because a Comment would have to be able to be linked to either a Post or another Comment. Yes, you could get into that complexity now, but I beg you, please slow down. We're not at that stage yet. Take it one step at a time and only add the complexity as it becomes obvious that it's necessary. Keep it simple. Stupid. Okay. So we're going to go ahead and we're going to use a very basic foreignId for, as we did with the User relationship, a foreignId for the Post class. This time when we constrain it, well, we could cascade on delete. When you delete a Post, all of the Comments on that Post should also be deleted. What else does a Comment have? Well, it doesn't have a title, but it does have a body. So we'll create longText and we'll enter the body here. All of these fields are going to be required, at least for now. And I think that actually is everything we

have a body. So we'll create long text and we'll enter the body here. All of these fields are going to be required, at least for now. And I think that actually is everything we need. So let's jump back into our terminal, run php artisan migrate. And sure enough, the comments table has been created. Let's take one last look in the database in TablePlus; here is comments at the top. We have our ID columns, our user_id and post_id, the body, and then our timestamps at the end. Okay. The last thing I'd like to do in this episode is fill out the relationships on the model classes themselves so that everything is set up and ready for us to start using those classes in our factories and seeded data. Let's start with our User model. I'm going to come to the bottom of this class and well, a User has many Posts. So let's create a new hasMany relationship for posts.

data. Let's start with our User model. I'm going to come to the bottom of this class and well, a User has many Posts. So let's create a new hasMany relationship for Posts. This is the syntax for that particular kind of relationship. And we have to specify the fully qualified class name of the Post model here. Because we've followed default conventions, we don't have to add any other information to this relationship. Of course, a User also has many Comments. So we'll add that relationship. Again, we need the fully qualified class name of the Comment model. And yeah, that's everything a User needs at the moment, right? A User has many Posts, a User has many Comments, we need to create the inverse inside the Post model, first of all. So a Post belongs to a User, a Post belongs to a User. And we define it in very much the same way. But note, we're using the belongsTo relationship method instead.

model, first of all. So a Post belongs to a User, a Post belongs to a User. And we define it in very much the same way. But note, we're using the belongsTo relationship method instead. Of course, a Post also has many Comments. So another hasMany relationship, we'll call it comments. And we need to just define the Comment fully qualified class name here. Does a Post have anything else? I don't think so. I think that's everything for now. Let's jump into the Comment model and fill that out finally. So a Comment also belongs to a User. So belongsTo and the User fully qualified class name, and a Comment belongs to a Post. So a Comment belongs to a Post. Brilliant. So we have all of our models set up with their relationships, we have all of the backing tables in our database up and running. The last thing I'd like to do is create some fake seeded data so that we can make sure that all of these models

we have all of the backing tables in our database up and running. The last thing I'd like to do is create some fake seeded data so that we can make sure that all of these models actually fit together correctly. And in order to do that, we need to turn to Laravel's model factories. So in the next episode, let's take a look at how we can build model factories, and then make use of them in order to create data in our application. See you there.