Migrations are like version control for your database, allowing your team to modify and share the application’s database schema. Migrations are typically paired with Laravel’s schema builder to build your application’s database schema. If you have ever had to tell a teammate to manually add a column to their local database schema, you’ve faced the problem that database migrations solve.
The Laravel Schema
facade provides database agnostic support for creating and manipulating tables across all of Laravel’s supported database systems.
Generating Migrations
To create a migration, use the make:migration
Artisan command:
php artisan make:migration create_users_table
The new migration will be placed in your database/migrations
directory. Each migration file name contains a timestamp, which allows Laravel to determine the order of the migrations.
Migration stubs may be customized using stub publishing
The --table
and --create
options may also be used to indicate the name of the table and whether
or not the migration will be creating a new table. These options
pre-fill the generated migration stub file with the specified table:
php artisan make:migration create_users_table --create=users
php artisan make:migration add_votes_to_users_table --table=users
If you would like to specify a custom output path for the generated migration, you may use the --path
option when executing the make:migration
command. The given path should be relative to your application’s base path.
Migration Structure
A migration class contains two methods: up
and down
. The up
method is used to add new tables, columns, or indexes to your database, while the down
method should reverse the operations performed by the up
method.
Within both of these methods you may use the Laravel schema builder
to expressively create and modify tables. To learn about all of the
methods available on the Schema
builder, check out its documentation. For example, the following migration creates a flights
table:
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class CreateFlightsTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('flights', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->string('airline');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('flights');
}
}
Running Migrations
To run all of your outstanding migrations, execute the migrate
Artisan command:
php artisan migrate
If you are using the Homestead virtual machine, you should run this command from within your virtual machine.
Forcing Migrations To Run In Production
Some migration operations are destructive, which means they may cause
you to lose data. In order to protect you from running these commands
against your production database, you will be prompted for confirmation
before the commands are executed. To force the commands to run without a
prompt, use the --force
flag:
php artisan migrate --force
Rolling Back Migrations
To roll back the latest migration operation, you may use the rollback
command. This command rolls back the last “batch” of migrations, which may include multiple migration files:
php artisan migrate:rollback
You may roll back a limited number of migrations by providing the step
option to the rollback
command. For example, the following command will roll back the last five migrations:
php artisan migrate:rollback --step=5
The migrate:reset
command will roll back all of your application’s migrations:
php artisan migrate:reset
Roll Back & Migrate Using A Single Command
The migrate:refresh
command will roll back all of your migrations and then execute the migrate
command. This command effectively re-creates your entire database:
php artisan migrate:refresh
// Refresh the database and run all database seeds...
php artisan migrate:refresh --seed
You may roll back & re-migrate a limited number of migrations by providing the step
option to the refresh
command. For example, the following command will roll back & re-migrate the last five migrations:
php artisan migrate:refresh --step=5
Drop All Tables & Migrate
The migrate:fresh
command will drop all tables from the database and then execute the migrate
command:
php artisan migrate:fresh
php artisan migrate:fresh --seed
Tables
Creating Tables
To create a new database table, use the create
method on the Schema
facade. The create
method accepts two arguments: the first is the name of the table, while the second is a Closure
which receives a Blueprint
object that may be used to define the new table:
Schema::create('users', function (Blueprint $table) {
$table->id();
});
When creating the table, you may use any of the schema builder’s column methods to define the table’s columns.
Checking For Table / Column Existence
You may check for the existence of a table or column using the hasTable
and hasColumn
methods:
if (Schema::hasTable('users')) {
//
}
if (Schema::hasColumn('users', 'email')) {
//
}
Database Connection & Table Options
If you want to perform a schema operation on a database connection that is not your default connection, use the connection
method:
Schema::connection('foo')->create('users', function (Blueprint $table) {
$table->id();
});
You may use the following commands on the schema builder to define the table’s options:
Command | Description |
---|---|
$table->engine = 'InnoDB'; | Specify the table storage engine (MySQL). |
$table->charset = 'utf8'; | Specify a default character set for the table (MySQL). |
$table->collation = 'utf8_unicode_ci'; | Specify a default collation for the table (MySQL). |
$table->temporary(); | Create a temporary table (except SQL Server). |
Renaming / Dropping Tables
To rename an existing database table, use the rename
method:
Schema::rename($from, $to);
To drop an existing table, you may use the drop
or dropIfExists
methods:
Schema::drop('users');
Schema::dropIfExists('users');
Renaming Tables With Foreign Keys
Before renaming a table, you should verify that any foreign key constraints on the table have an explicit name in your migration files instead of letting Laravel assign a convention based name. Otherwise, the foreign key constraint name will refer to the old table name.
Trackback 1