All language subtitles for 3.creating-the-post-model

In this lesson,

we will create a Post model so that we can store blog posts to the

database. If you remember from the previous lesson, Model class is just

an abstract presentation of some database table.

However, our blog database is empty.

We need to create the posts table before we can use it. To create a new

table with Laravel, we need to utilize migrations.

You can make a new migration with Artisan.

The command follows the same principle; we type make,

followed by what we want to make, in this case migration, and then

we specify the name for that new migration. And we will use this

command later in the course; however,

in this case we can use one command to create a model and migration at

the same time. I can use this artisan command to create a new Post

model, but if we also add this ‑‑migration flag,

Artisan will assume that we want to make a new migration too, and this

migration will create a table in the database for the Post model. The name

of the table will be derived from the model's name.

Migration will put the name in snake case and make it plural.

Model names are usually in camel case, so if our

model had two words, like BlogPost,

both words would be capitalized like this, and the corresponding

table name should then be plural and in snake case, like this.

Snake case makes all of the letters lowercase and it uses

underscores to separate words.

Okay, so after you run the command,

you can see that the model is successfully created and the new migration

is added to the collection of existing migrations.

Each migration has a timestamp in the name so that

Laravel knows how to order them.

The purpose of the migration is also clear.

It says create_posts_table.

Let's check out this migration file in our project.

You can find all of the migrations inside of the database, migrations directory.

Notice that we already have some default migrations for users,

passwords, jobs, and tokens.

These are provided by Laravel, but we don't need to worry about them now.

They are just here because Laravel assumes that most

applications will need these tables.

Let's click on the new migration to see what it looks like.

Just like we discussed in the previous lesson, here is the up method that

actually defines what the migration will do. With the help of the Schema

facade, we are creating the new posts table.

These two columns are provided by default.

The id column should be present in every table.

It is the primary key.

The timestamps method creates two columns,

one for recording the time when the row is created and one to

record when that specific row is modified.

We can leave these two methods and also add two of our own to

create the title and the description column.

The title will be a simple string, but the description could be a

longer text, so I will use the text method.

This Blueprint table instance has a special method for each type of data and

you can find all of the available column types in the Laravel's

documentation. Search for the available column types in the section about

migrations, and there you should find this list. As you can see, a lot of

different column types can be defined with these methods, so you can be as

specific as you want to be.

Our table is simple, so I will just use these two methods

and leave everything else as it is.

The down method will simply drop the posts table if it exists.

Okay, now that we defined the migration,

we also need to run it to commit the changes to the blog database. To run

all of the migrations from the migrations directory, you can use the

artisan migrate command. Along with the posts table, this will also create

all of the other built‑in tables in Laravel, like the users table that we

will use later in the course.

If you get an error,

that probably means that you didn't configure the database correctly. Try

to find the reason why this error occurred and fix it.

If you get stuck,

you can write me a question in the discussion. But if all of the

migrations run successfully, then congratulations, your database

connection is set up correctly. To check what these migrations did,

you can inspect the blog database from the SQL command line, or if

you have a setup like me,

you can use phpMyAdmin and click on the blog database. Here you can see the

new posts table along with the other built‑in tables provided by Laravel. And

it seems that this table has all of the columns we required, so now we can

finally start working with the posts model.

You can find it inside of the app, Models directory. Here we already

have the built‑in User model and our own Post model.

If I click on the Post file,

you can see that the Post class doesn't really have a lot of code.

Most of its functionality is extended from this eloquent

Model class. In the previous lesson,

I told you that this Model class has a property mapped to each column from

the posts table, but where are these properties defined?

The answer is they are not.

These properties are dynamically generated from the column names when

you use this Model class. Also, Laravel will assume that you want to map

the model to the table with the same name.

Well, not exactly the same, the table name is in snake case and it's plural,

but you get what I mean.

If you want to go outside of this norm and name your table

differently, you can specify the table name inside of the

protected table property, but unless you have a good reason to do that,

it's always better to stick to the standard.

It makes everything easier.