Let's create some models. Now we're not going to create everything in this episode. I don't necessarily want to take everything piecemeal, but I do want to break it up into smaller chunks just to make it a little easier because you know, there are some design decisions that we need to make. For example, you know, we of course need a User just about every application needs a User so that we can authenticate.

of course need a User just about every application needs a User so that we can authenticate. But then we need to decide, okay, how much information do we want to store in the user table as opposed to something like the profile. Because if we look at, you know, any kind of social media application, you sign in with a set of credentials and there's really nothing as far as those credentials are concerned, that links it to a profile.

as those credentials are concerned, that links it to a profile. Now, of course, on the backend, yes there is that link, but you know, you can sign in with a username or a phone number or an email address and that is not displayed anywhere else. You usually have a display name and a handle and things like that. So as far as our design is concerned, I think we should follow something similar to the point

So as far as our design is concerned, I think we should follow something similar to the point that we have a User that is just for authentication and then we have a Profile that kind of combines everything together. Because once again, if you start looking at social media applications, I mean, you know, a lot of them these days allow, uh, multiple people to handle or work with multiple Profiles. So really whatever posts that we make don't belong

multiple people to handle or work with multiple profiles. So really whatever posts that we make don't belong to the User, they belong to the Profile. And the same is true for likes and following and things like that. So then the question becomes, you know, how do we create this relationship between the User and the Profile? You know, because you know, obviously a one-to-one is the most simple way.

You know, because you know, obviously a one-to-one is the most simple way that we can approach that. But what if we wanted to allow multiple Users to access multiple Profiles? That would mean you know, a manyToMany relationship. And that of course greatly increases the complexity of the application because then you have to be aware of what Profile is currently active for a given User, what Profile would be considered the primary.

what profile is currently active for a given user, what profile would be considered the primary profile for a user. And so, you know, we could take this in a variety of different ways. We could say that okay, there is a manyToMany relationship between the user and the profile, and then on the software side, we could just limit it to one user and one profile. That way things are kind of set up so that if we ever decide

to one User and one Profile. That way things are kind of set up so that if we ever decide to expand upon that, you know, the backend is is ready for us. But again, that increases complexity. So I think for the sake of simplicity, we'll just go with the one-to-one relationship, one User, one Profile. Now of course we already have the User model and I don't really think that we need to add anything here because this is purely for authentication purposes.

and I don't really think that we need to add anything here because this is purely for authentication purposes. What is your email? What is your password? And then voila, however, you know there is the name column that we could or could not work with. I mean, because really the, the name doesn't mean anything as far as the account is concerned because everything is going to tie to the profile. So we could get rid of the name

because everything is going to tie to the profile. So we could get rid of the name and let's go ahead and do that. It's not like we can't add it back later if we decide that we need it, but I don't really think we will need it. So we'll just get rid of the name and yeah, everything else should be fine there. So that now we just need to use php artisan to make our new Profile model. We want the migration as well as a factory.

to make our new Profile model. We want the migration as well as a factory. And we'll go ahead and start with the migration. That way we can go ahead and define what we need for that table and then we will set up the relationships and all of that stuff. But of course that's the model. We need the create_profiles_table migration. We need the id and the timestamps,

We need the createProfiles table migration. We need the id and the timestamps, but we want to set up that one-to-one relationship with the User. So we'll call that user_id. We want this constrained. And because this is a one-to-one, we might as well cascade on delete. If this were a one to many, then no we would not want to do that, but it's not.

If this were a one to many, then no we would not want to do that, but it's not. So we're gonna continue on to where we will then have the display name and then of course we want the handle, except that our handle needs to be unique. So let's add unique to that column. But then, you know, let's have a bio because bios are useful and pretty much every social media platform allows you to create a bio for a profile that's not.

and pretty much every social media platform allows you to create a bio for a profile that's not to everyone would want to write a bio. So we will be sure that that is nullable. And then we need the avatarUrl, which will also be a string and we'll just call it avatar, URL, I think we called it the avatar when setting up the views. But I think avatarUrl is much clearer as to what we're storing here. So we'll just use avatarUrl.

as to what we're storing here. So we'll just use avatar_url and we will make the necessary changes where we need to, but at the same time, that should be optional as well. So we will set that as nullable, then we need our timestamps. And yeah, I think that that is going to be sufficient. So now let's just set up our motto, relationships. Let's open up User so that we can add the public function profile, which will return a hasOne relationship.

Let's open up User so that we can add the public function profile, which will return a hasOne relationship and we will simply return. This hasOne Profile class, then we essentially need to do the reverse of that inside of Profile. So I'm just gonna copy and paste because that makes it a little bit easier, except that the name of this method will be user it belongsTo, and the method will return. This belongsTo User class.

and the method will return. This belongs to User class. Now we should go ahead and set up the fillable array. So I'm going to copy what we have from the User model and paste that here because it just makes it a little easier to get started. And then well, what, let's open back up the migration because we have display_name, we have handle_bio, all that stuff.

because we have displayName, we have handle, all that stuff. So displayName and then handle, and then bio, and then the avatar, URL. And those are it. Of course, it helps if you can type it all. It also helps if you can type it correctly. Let's make sure that that's it. displayName, handle, bio and avatar. URL I should have just copied and pasted that.

Display name, handle, bio and avatar. URLI should have just copied and pasted that. That would've been a lot easier there. So we have our migration, we have the model relationships all set up and ready to go. Let's open up the ProfileFactory because we want to be able to create these on the fly as we develop our applications. So let's set $userId to UserFactory. Then we want the display name, which uh, let's use Faker.

So let's set userId to userFactory. Then we want the display name, which uh, let's use Faker to generate a name for us. So we'll call Faker::name. Then what we have the handle, which we can use Faker once again. But we do need this to be unique. And then we will call the username method, 'cause a handle is a username. Then we have the bio, which once again, let's use Faker,

'cause a handle is a username. Then we have the bio, which once again, let's use Faker, but let's do sentences and let's do, I don't know, 10. That might be a little too much. Let's do five. That's too much. Let's do three. And then finally avatar, URL. And once again, we will use Faker and call imageUrl. The width, let's do 200. The height, let's do 200. And then category will be people.

The width, let's do 200. The height, let's do 200. And then category will be people. Although I guess really what we should do is see what the dimensions are for our images. So when it comes to these avatars, that really doesn't tell me what it is, or at least the size of it if we, there's no properties here. But one thing we can do is we can go to explore and we can go to the properties of one of these,

But one thing we can do is we can go to explore and we can go to the properties of one of these, and that will tell us the dimensions, which is 90 by 90. Okay, that's good. So let's change that from 200 to 90 by 90, which that's even better. And that should be it. We're not gonna write any seeders yet because I want to get everything else ready to go before we seed the database,

because I want to get everything else ready to go before we seed the database, but this is gonna be it as far as our Profile is concerned. While we could have taken many different approaches, we decided on the one-to-one relationship between the User and the Profile. Just to keep things simple, we created the micro migration, we set up the relationships and created the factory. So that's next. We can focus on defining the posts.

So that's next. We can focus on defining the Posts.