As we discussed in our previous article, database migrations allow you to define changes to your database so you can easily apply the changes everywhere you maintain a copy of the database for the application. The migrate family of commands gives us control over applying those migrations to the database.
When Should You Use It
Any time you’re editing the structure of a table.
As a quick review here’s what the migrate family of commands looks like in the help display.
The migrate:install command creates the “migrations” table inside the database. This table is used to keep track of the migrations that have been run against the database. I’m guessing this command exists as a form of completionism because some of the commands below automatically create this table when it’s missing.
The migrations table itself is super simple:
The migrate:status command displays the status all the migrations you have defined.
The main items to highlight here are:
The “Ran?” column which display if the migration has been run against the current database
The “Migration” column which displays the name of the migration
The “Batch” column which displays in what order the migrations were run.
In the example above I ran the first three migrations separately but if I had run them at the same time I would have ended up with with the results below.
The migrate command runs any migrations that have not been run against the database. It uses the up() function inside the migration to determine what to do.
Now if we look at the current status we’ll see that “2019_10_11_011555_create_tasks_table” was applied in it’s own batch.
The migrate:rollback command takes the list of migrations in the last batch number and runs their down() function.
Now we can look at the status and see that “2019_10_11_011555_create_tasks_table” is no longer listed as being run.
The migrate:fresh command deletes all existing tables and then runs all the migrations.
Be careful with this command. “Dropped all tables successfully” includes any tables that aren’t being managed by the migrations. We’re in the process of migrating to Laravel and running php artisan migrate:fresh deleted all the tables that we hadn’t created using Laravel migrations. Thank goodness it was on a development VM. :-)
The migrate:refresh command rolls back all the migrations and then runs them again.
Now if we look at our migration status we’ll see everything was applied in one big batch.
The migrate:reset command rolls back all the migrations and then stops.
If we look at migrate:status now, none of the migrations have been run.
When Do I Use These Commands?
status, migrate and rollback are the bread and butter of this family of functions. You’ll be using them all the time.
fresh and refresh are used if you need to reset your database to a clean state.
reset is a mystery to me. I can’t think of any good reason you would want to rollback every migration and then stop. Sound off in the comments if you have an explanation.
Hopefully this has been as helpful to you as it has to me and check back soon for more artisan commands.
Like this post? Don't forget to follow us on Twitter and Facebook for updates.