[Feature Request] Support migration steps in Recipe::getMigrations()

[StrykeSlammerII]

Currently:

• getMigrations() in the Recipe file returns a flat array of classes.
• Running php bakery bake for the first time, or php bakery migrate later on, runs all of these migrations as a single step.
• Assigning different migrations to different steps can be done in either of two ways:
  • Use the -s flag on php bakery migrate
  • Repeatedly comment out different migrations from getMigrations() before running either php bakery bake or php bakery migrate

I have a project where I would like to group my migrations in separate steps from the core UF migrations.
Further, I would like to group my migrations in different steps themselves.

Also, it happens that I am changing DB engines after having developed multiple such stages of migrations.
In order to separate the migration steps that I want, I will have to edit getMigrations() multiple times rather than running php bakery bake once on the new database.

Would it be possible to return a nested array in getMigrations() for each step?
Something like

public function getMigrations(): array
{
    return [
        //same step as `php bakery bake`
        \Project\App\Database\Migrations\Migration0::class,
        //step 1
        [
            \Project\App\Database\Migrations\Step1\Migration1::class,
            \Project\App\Database\Migrations\Step1\Migration2::class,
        ],
        //step 2
        [
            \Project\App\Database\Migrations\Step2\Migration3::class,
        ],
    ];
}

Something other than nested arrays would be acceptable, that's just the first backwards-compatible option that came to mind.

[lcharette]

getMigrations() from the recipe right ?

The issue I have with this is migration dependencies. If Migration2 depends on Migration3, then you'll get in a pickle.
A better solution would probably be to allow for a specific migration to be rundown. Again, tricky because of dependencies, but doable.

[StrykeSlammerII]

getMigrations() from the recipe right ?

Yes. I tried to reference that in the first bulletpoint but wasn't explicit.

The issue I have with this is migration dependencies. If Migration2 depends on Migration3, then you'll get in a pickle.

🤔
My use case avoids that because I manually run the groups in development order, so I know there are no dependencies on later steps.
But you're right that things would break if the migrations aren't grouped correctly.

If they were seeds I could get by with feeding a master seed in the recipe, but adding "master" migrations feels like too much extra work

[lcharette]

Actually, a seed (or custom function) could be a solution for you.

1. Disable all built-in migrations
2. Create a seed/command that manually run each migration in the order / step you want

or

1. Customize bake so it doesn't run migrate
2. Add your custom seed or command to bake

The migrator doesn't do much. That part could be made it's own public method you could reuse. Just pass the class one by one in batch.