Example scenario for a migration change in production system?

I don't fully understand the concept of migrations especially when you want to change something afterwards.

Let's say I have this migration file: 2014_1012000000_create_users_table.php and now I want to add another column or want to change some attributes. The docs state that I need to write another migration file for doing this task. Ok so far so good.

But here is what I would do. Instead of writing another migration file I just would modify the column manually via my database tool and than just change my originally migration file.

// from
$table->string('password', 60);
//to
$table->string('password', 60000);

Is there any error in reasoning I made? I think my way is more convenient and faster. What is you're process when you need to change something afterwards?

rwdevguy

10 years ago

Best Answer

Level 11

It's really judgement call. IMO, for this particular example, it's fine to do what you have done.

If you're a one man team and you've not even hit the production stage then by all means just change the original migration and edit table(s) manually.

Now, imagine you're in a larger team and you're production environment has gone live and you're boss (or whoever) wants a new feature or an existing feature updating. Take these two examples:

A simple one at first, you just need to add a phone number column to the users table. You would create a new migration that adds the column to the table e.g.

class AddPhoneNumberColumnToUsers extends Migration {

    public function up()
    {
        Schema::table('users', function ($table) {
            $table->string('phone')->nullable(); //or however you'd prefer to store phone numbers
        });
    }

    public function down()
    {
        Schema::table('users', function ($table) {
                $table->dropColumn('phone');
        });
    }
}

Now, all you'd have to do is run php artisan migrate for that column to be added, and once it's committed the rest of your team would be able to pull that down a run it as well. Fair enough, it would be rather simple to just email them saying the needed to add a phone column to their users table thats a varchar and make it NULL and then just change the production db when it goes live. Then, the boss comes back later and says actually we don't need that feature anymore. Rolling back the migration would be rather simple, but again it wouldn't be difficult at all to do the process manually.

Now, for a slightly more involved example. Same situation, boss wants a new feature adding, but this time involves the creation of 5 new tables and an update of 3 more (just keep in mind that all these changes can be kept in one migration file as well if you wanted). If you weren't using migrations then you'd probably have to dump the database and send the dump to everyone, or at least create a file that has all the necessary queries to do this at which point you're kind of reinventing the wheel in a way that is less readable and probably doesn't contain rollback queries.

So, I'd say if you're only making small changes that won't really break anything then go for which you feel is best/easiest. However, if you've hit production and/or there are more developers in you're team then go for using migrations.

Hope this helps!

2 likes