Question 242259 in Laravel Question posted in
The official Laravel Documentation can be found here.

Laravel migration question about when should we use hasColumn function?

Good morning y’all!

I am facing some discussions at my workplace about laravel migrations, we do use laravel for backend and I started a comment on a code review about checking if the column exist, and only if does not exist we try to add a new column:

public function up(): void
{
    Schema::table('testing', function (Blueprint $table) {
        $table->boolean( 'boolean_test_value' )
              ->default( false )
              ->after('some_other_column' );
    });
}

And I am suggesting this as solution for it:

public function up(): void
{
    if (!Schema::hasColumn('testing', 'boolean_test_value')) {
       Schema::table('testing', function (Blueprint $table) {
           $table->boolean( 'boolean_test_value' )
                 ->default( false )
                 ->after('some_other_column' );
       });
   }
}

Can anyone explain why this can be a wrong thing to do? I am facing some replies that says this isn’t recommended, I can’t see why, is anyone with the same opinion could express why this isn’t a good practice?

Tags:

2

Answers


  1. 0

    I had to use the hasColumn check in some rare occasions.

    First of all the meaning of migrations are to run smoothly and create your database structure as it should. Migrations should be depended on each other and have a "flow" and by that i mean that in your example the some_other_column is supposed to have been created in a previous migration otherwise the migration will throw an error as it should.

    So normally in a project when you run your migrations they should be already in place all the columns and everything without having to check them, otherwise you must allow errors to happen so you can fix. In this case if for any reason the testing column is created you will get a "free pass" from the migration but is it really what you want? Why would this column not have been create already in a previous migration? Was it necessary to happen?

    In my prio experience i remember very limited edge cases where the backend was deployed in multiple environments. Every environment of course had it’s own .env file etc etc. One of the requests was that "we want column X in environment ENV_1, but this column should not appear in the other environments". The project specs was that each environment had it’s own database and generally it was completely stand alone. But the problem was that the backend was the same of course so the Backend had to treat each environment with it’s own "unique" things.

    So it was the only way to have checks and one of them was using the hasColumn to ensure that if that column exists then run the migration, you get the main idea.

    In a well structured project you don’t have to ensure that columns are there, instead you want to see if a migration fails the reason it failed.

    For edge cases well that’s another story but i would definitely not call it a good practise to have checks like this in migrations. If a migration is throwing an error, the error should be fixed not bypassed.

    Login or Signup to reply.
  2. 0

    If you need to check if the table has a duplicate column you are already doing something wrong. If the column exists you WANT that migration to fail, not be ignored.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search