Multiple Migrations That Reference Each Other Not Migrating In Correct Order

[danielheramb]

Do you have a recommended solution for when a package has multiple migrations that need to be migrated in a specific order due to foreign key references? Currently, all migration files are prefixed with the same timestamp when published, which leads to them being run in the alphabetical order of the original migration filenames.

The best options I could come up with were:

1. Placing all tables that reference each other in the same migration file that loads them in the correct order. (bleh)
2. Prefix the migration file names and corresponding class names with some string that orders them correctly. (less bleh)

EXAMPLE:
Cars Migration (references owners): database/migrations/create_cars_table.php.stub

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateCarsTable extends Migration {
    public function up() {
        Schema::create('cars', function (Blueprint $table) {
            $table->id();
            $table->string('name', 250);
            $table->foreignId('owner_id')->constrained('owners');
        });
    }

    public function down() {
        Schema::dropIfExists('cars');
    }
}

Owners Migration: database/migrations/create_owners_table.php.stub

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateOwnersTable extends Migration {
    public function up() {
        Schema::create('owners', function (Blueprint $table) {
            $table->id();
            $table->string('name', 250);
        });
    }

    public function down() {
        Schema::dropIfExists('owners');
    }
}

When published, they are renamed to:
database/migrations/2021_02_09_231731_create_cars_table.php
and
database/migrations/2021_02_09_231731_create_owners_table.php

meaning that artisan will attempt to migrate the cars table first since that file name is alphabetically before the other. This throws a QueryException since the owners table doesn't exist yet when referenced by the foreign key in cars

[freekmurze]

Currently I use option 1 for the small number of packages that need this.