Update table from migrate

Hi, I have always used laravel in projects with existing databases, but now I'm creating a project using migrates.

I often create a migrate and run it, forgetting to enter a column, once it's done, how do I re-run it to add the missing column?

For example, if I have this migration already executed on db:

        Schema::create('users', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });

And I forgot the "avatar" column, it becomes:

        Schema::create('users', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->string('password');
            $table->string('avatar')->nullable();
            $table->rememberToken();
            $table->timestamps();
        });

how do I make it re-run? Artisan give me an error because the table already exists...

deansatch

8 years ago

Best Answer

Level 24

create a new migration... make:migration add_avatar_to_users

then

 Schema::table('users', function (Blueprint $table) {
            $table->string('avatar')->nullable()->after('password');
        });

Note: don't forget your "down" too for rollbacks...

 Schema::table('users', function (Blueprint $table) {
            $table->dropColumn('avatar');
        });

EDIT: added the ->after() part just to match your OP aims

3 likes

Stratos

8 years ago

Level 14

If you're still in local state and don't want to keep making more migrations for small changes, you can just modify your original migration to match your second example and then run php artisan migrate:refresh.

Note that this rollsback the whole database so any information is lost, but the next time you would run your migration, every table gets created correctly with 1 migration file rather than 1 faulty one and 1,2,3+ patches.

If you're modifying production databases however, rolling back the whole database is not an option so you should just use the approach described above.

Please or to participate in this conversation.