[Proposal] Make the migrations atomic

[sobhanatar]

For now the migrations don't run in atomic way. Means that if you have the following code, first it creates table, then columns and if everything goes fine, then create the index. Now if you have any problem like duplicate index name or anything that prevents the migration from creating the index, on next run - after correcting the problem - you will get error `Table 'xyz' already exists.

Schema::create('xyz', static function (Blueprint $table) {
    $table->bigIncrements('id');
    $table->unsignedInteger('user_id')->nullable(false)->index('user_index');
    $table->unsignedInteger('username')->nullable(false)->index('user_index');
});

But if the creation of table and other after creation processes become atomic this problem won't happen.

Do you think it's ok that we have this feature, or atleast have it as an option on command?

[mfn]

This is already done automatically via withinTransaction iff the database supports it.

For further complication, i.e. regarding MySQL, see e.g. #1645

[prezire]

For now the migrations don't run in atomic way. Means that if you have the following code, first it creates table, then columns and if everything goes fine, then create the index. Now if you have any problem like duplicate index name or anything that prevents the migration from creating the index, on next run - after correcting the problem - you will get error `Table 'xyz' already exists.

Schema::create('xyz', static function (Blueprint $table) {
    $table->bigIncrements('id');
    $table->unsignedInteger('user_id')->nullable(false)->index('user_index');
    $table->unsignedInteger('username')->nullable(false)->index('user_index');
});

But if the creation of table and other after creation processes become atomic this problem won't happen.

Do you think it's ok that we have this feature, or atleast have it as an option on command?

I've always been a victim of this flow. Thanks for proposing.

[sobhanatar]

This is already done automatically via withinTransaction iff the database supports it.

For further complication, i.e. regarding MySQL, see e.g. #1645

Thanks @mfn
Seems it's controllbale that way.

[dinamic]

Changing a database table in some way - adding/modifying/deleting a column is rarely supported inside a transaction. It's definitely not supported with MySQL which I imagine most of us are using.

The way to control this is by having unit migrations - one migration, one change. Need a column with an index attached to it - have two migrations created - one for the column and another one for the index.