9 hours 41 minutes
Hi. Welcome back to Module three. Environment set up.
This is less than 3.7 modeling with lair bill.
Now, when we model with level, we're gonna use some PHP partition commands These commands willing to create a PHP object that represents a record.
An easy example is that our user model
links and represents the users table in the database.
We can also define relationships in the model.
This is separate from database constraints. Constraints still need definition in the database.
Some full effective elders Onley used relationships on this layer, and this is one reason you may find databases without the constraints implemented. It's because these full stack
frameworks make it easy to just do it on the application layer and then not do it on the data base layer. But you should always put in your constraints unless you have a good reason not to, and a good reason not to means that you will. You will have a very specific reason why you are not doing that
now. When we begin to use O r m
object relational modelling removing closer or deeper into object oriented programming.
Now we are going to go that deep into object oriented programming. We're just going to go deep enough to where we can easily generate fake database data so that we can test our database. Terrible also provides a neat tool for testing your models, and that's Tinker,
and we'll take a look at that in this lesson as well. With that said, let's move over to our virtual environment.
All right, let's go ahead and get started with some Larible modeling. Now, if you need to find the documentation on this component, all you need to do is Google Larible. Eloquent, eloquent is thesixties we're dealing with,
we need to make a model with a migration, which is going to be this command.
So to get started, we're gonna go ahead and get rid of the default users table that comes with it. Larible installation because they're not gonna be using it.
I also want to get rid of the password resets table,
and this is in the
shared database migrations, and there's one more file we need to get rid off, and that's in the APP.
We need to get rid of the user model. That's the that's the user model. The default user model that comes with narrow going and get rid of that.
go ahead and exit out of this and I'm gonna clear the screen.
I'm gonna vag Grint Ssh! To open a shell into the bag Grant virtual machine that is running a boon to Lennox.
Then I'm gonna ls cd intolerable.
And then I'm going to do a PHP
when we saw that that user file popped back up in that directory
because that's the model and then it will also put a user migration file back in the database section.
So we go and we look at the data base
Would you go ahead and we're gonna just make it very simple,
Very simple. Migration are user class is not going to be that complicated at all.
So, in fact, I'm just gonna just do table,
and so Michael and we want to get that syntax correct, because if we forget, the dollar sign would forget the semicolon,
it will crash and not run correctly.
And let's go ahead and hit the up arrow in our shell to go back to our last command. But we're not gonna make another user model. In fact, it would air out if we tried to, because it would say that it already exists.
We're gonna say, Look,
we're gonna say that users have books, so we're just going to say we're gonna make a book model with the migration.
if we edit this file,
we're gonna go ahead and add another
columns. We're gonna keep it simple again. So name the name of the book
on a table.
It's a big manager
user. I d The user owns the book.
I'm gonna make that unsigned
because big increments is not really a data type. It's combining a few ideas into one command it saying it's a big manager, It's unsigned and it automatically increments. And that's so that we don't have to run those three commands independently
level package to the packages them together and this one command.
And then to make sure that we can
create a foreign key to that field, we need to make sure that it is of the same data type,
which is a big energy for use a regular energy. It would not work.
I was going to save that.
Let's go ahead and run a PHP. Our petition
cool and fresh
my great fresh. Okay,
here we go.
Let's see what we got for an air.
So this air occurred because I recently changed my development space,
so actually need to go and at the password that level is trying to use in trying to use
and the dot m file. So database route
password is Sai Buri
And if I saved that and run the same command with up an inner,
you have a successful migration. Now, if I go into my
the beaver refresh,
I see my larible database,
I see my books
with the name and the user I d.
I see the users with the name
so we know how to set up a foreign key constraint in literal. We did that in the previous lessons. So we're just gonna find a relationship in our model class.
Let's go ahead and do that.
We need to go to the file that represents the model that's in the APP folder,
and we'll see these two
files, user and book that represent those models. So let's go into our user
We're going and edit this. It's empty at the moment,
nice and simple,
and we're gonna add in our relationship for books. And the relationship relationship is going to be
that a user can have many books, so let's go ahead and enter that.
So the has many relationship definition isn't on this page, so we need to find it. So I'm just going
go back to Google and type in level has many
almost like we're on the right
page. So we're gonna one too many
and we can see that it's pretty simple.
This post comments has many
So Post can have. Many comments were, say, a user can has many books,
so let's go ahead and type this in. And but use our books, public function
we're going to return.
on we're gonna say
Go ahead and save that.
Now there is some magic that Larible is
performing for us in the background, for example, we haven't indicated which key
should affiliate this relationship, and that is because liberals making assumption. So we following. If we follow the name in semantics, that level expects we will not have any problems now if we change the naming semantics. Then label will start to have problems, but there are ways to tell arable that you've changed things,
but it's easier to try and just follow their
name in semantics if you can. And the name is semantics for this is that when we say this has many books, it's gonna look for the book model, and it's going to assume that the user
is part of the name of the column. So it's gonna look for a column name, User I D. And it automatically affiliate that in the relationship for us. That's why we're not having to indicate that anywhere
now to demonstrate the relationship working. Let's go ahead and add in a couple of dummy values. So we're going to users
going to Data and D Beaver. I'm going to click this plus symbol,
and I'm just going to add in a user of cyber a
and hit save. I'm not even gonna bother with the creator updated at.
Then I'm going to books.
I have two books
just to show that it's a one to many.
So again, the plus
I'm gonna say name,
one user I d. One because cyber a user is user. I d want to save that.
Go ahead and add in another record
and look to
He's already won again and save that.
Okay, so now we have Book one, a book to that's owned by user I. D. One We come and look at the user's table can see that he's already one is Sai Buri.
So let's go back into our shell
and let's type in PHP partition
And that's gonna that's gonna bring us into the Tinker program made by Justin Hillman Heilman. Think I said his name right?
And all we need to do is say, Let's say user
now. This is not saying, Find one or anyone. It's saying, Find the one with I D. One, which will be Sai Buri. So I'll hit. Enter
and sure enough, we got it.
Now let's do an arrow and save books.
And it returned both those books based on the user found so we could do this kind of stuff. Can say user variable, which starts with a dollar sign, equals user colon, colon, Find one.
Okay, so now user, is that assigned is that is that user that we found cyber, then we could say, OK, user, what books do you have by doing this?
And that brings back our books? And that will be really useful when we're seeding the database because we'll be able to go across those relationships, bring back the data and inserted into the related tables and follow those constraints that we create as well.
So that brings this section of this lesson to an end. Hope you were able to get all that modeling done. And if you have questions, the specific parts of the Larible documentation is directly related to what we're doing.
Specifically the migrations and the creating the model parts of you want to be careful because there are levels a pretty big framework, and
there are sections of it that we are not using at all. And it would be beneficial for this course to get lost in those sections.
So that finishes this section. It's time to head over to the summary,
and that brings us to this summary or the modeling with terrible summary. So what did we do in this lesson? Well, we created a level model with the migration file, which was the same type of file, but migration file. Anyway, it was the same type of father we actually made in the migration lesson. However, in this lesson,
we created a model with a migration file
and we also to find a relationship in that model. And we'd used Tinker to test that model.
So that brings this lesson to a close. And I will see you in the next lesson. Thank you.