Original subtitles

It's time for the summary of this module.

In this module, we established a connection to the real SQL database.

First,

we discussed the supported database management systems you can use in Laravel.

You need to choose one of them and install it,

but make sure that the installed version is supported and check if PHP has some

special dependencies for working with that database system.

Once you do that,

you can configure the connection inside of the database PHP file.

However, since all of the actual data there is pulled from the env file,

we need to update these environment variables.

Here, we can set the specific system, database host,

port, database name, and access details.

Standard practice is to name the database after the project.

You need to create this database in your system of choice by

either using command line interface or some other graphical

software for managing databases.

We can check if the connection was established by using the artisan db command.

If this command redirects us to the native command

line of the database system we use, that means that the connection is successful.

Once the connection is established,

you can start using the database through Laravel.

DB façade, also known as Query Builder,

allows us to retrieve data from the database by using object‑oriented practices,

instead of writing raw SQL queries.

By chaining methods, we can construct complex queries and get the required data.

We will not utilize the Query Builder in this course,

but you should be familiar with it in case you need to perform some

really complex queries that require high performance.

Also, these query methods can be used on models.

So in this course, we will use models to manage resources from the database.

Model is a simple PHP class that extends the Model class from the Eloquent ORM.

Eloquent object‑relational mapper will map the Model

class to the table in the database.

It will also dynamically create a property for each column

from that specific table so we can use the Model class to

retrieve records from the database.

For example,

the all method will return all of the records from the table

in the form of an Eloquent collection.

This collection object can be looped over so each one of these records

from the database will be represented as an object,

an instance of the Model class,

and then we can use these dynamic properties to

access specific parts of that record.

We can also use this find method to retrieve a single

record from the database by the provided ID,

but of course, before we can even use this model,

we first need to create the corresponding table in the database.

To create new tables and alter the existing ones, we can use migrations.

Migrations are used like a database version control system.

You can create a new migration with the make migration artisan command.

This will create a new migration file with the two methods, up and down.

Inside of up, we define what this migration should do.

We can use the schema and blueprint classes to create tables and

define what kind of columns this table will have.

The down method should do the opposite,

but this method will only be used if you try to roll back this migration.

To run all of the migrations and commit the changes to the database,

we need to run the artisan migrate command.

Once the table is created, we can make a new model to manage the post resource.

You can also just add the migration option to this model

command to create the migration at the same time.

This is only if you didn't create the post table already.

The special migration option will assume that you want to create a

corresponding table with the name of the model,

but of course the name of the model will be converted from the

camelCase to snake case and it will also be plural.

This is also the same standard that Eloquent follows

for connecting models and tables.

By default, the Post model will take data from the post table.

However, if you want, you can change that with the special table property,

but I wouldn't recommend it unless you have some special reason.

After we created the new Post model,

we used it to store a new post to the database.

We took the user input from the request object and placed it in the

appropriate properties of the new Post instance.

Then we committed the changes to the database with the save method.

Only after you save the model instance,

this post will actually be inserted into the post table.

We also learned how to retrieve all of the records from a

specific table by using the all method.

Once we have this collection of posts,

we can pass it down to the template as a second argument of the view function.

Inside of the template,

we can loop over all of the records with the for else or for each directive.

However, if we use for else,

we can also define what will be rendered if the collection is empty,

and that's it.

We finally started putting resources in some kind of permanent storage.

In the next module,

we will continue implementing all of the resource controller

actions with the help of the Post model.

I will see you there.