Laravel, migrate easier than before

Laravel is one of the most amazing frameworks for back-end development. It comes with huge well structured and widely used features. One of the enjoyable things to do in Laravel is to build your database, the framework provides a way to build your tables without actually going to the database manager such as phpMyAdmin, pgAdmin or whatever DBMS you use.

The idea why Laravel has Laravel Migrations is the ability to perform sort of version control to your database so you can revert back to the previous version or deploy the next version for your tables.

Moreover, structuring your DB via Laravel migration files, helps you to easily share the changes with your team because the files are finally php files that can be pushed to your project repository.

Basically, Laravel provides these commands for migration in their artisan

• migrate:fresh Drop all tables and re-run all migrations
• migrate:install Create the migration repository
• migrate:refresh Reset and re-run all migrations
• migrate:reset Rollback all database migrations
• migrate:rollback Rollback the last database migration
• migrate:status Show the status of each migration

In this article I am not going to explain all of these commands, but still want to comment on a mistake that some developers make, and here, I would like to post a sample of a migration file of users table

class CreateUsersTable extends Migration
{
    /**
    * Run the migrations.
    * @return void
    */
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }
    /**
    * Reverse the migrations.
    * @return void
    */
    public function down()
    {
        Schema::dropIfExists('users');
    }
}

Imagine that we run the migrate command, then decided to add a phone number field.

Some developers think that after setting up the table and running the migrate command, there is no other chance to add extra fields to the table because the table has already been created and the migrate command will ignore the new field we added. I know someone who was manually creating the field in phpMyAdmin and also add the PHP code in the migration file just to keep them synched.

Well, the reason for that is because he is thinking that each migration should represent a table, but NO, a migration file may contain any command and does not always create a table.

So, if you want to add a phone field to the “users” table, you should create a migration that just adds that field like this:

php artisan make:migration add_user_phone_field

and the code in this migration will select the “users” table and make the required changes like this:

public function up()
{
    Schema::table('users', function($table) {
        $table->string('phone');
    });
}
// And don't forget to add the rollback option:
public function down()
{
    Schema::table('users', function($table) {
        $table->dropColumn('phone');
    });
}