Migrations history is not filtered based on enabled migrations namespaces

[djagya]

Lets say in our app we have a module (for example app/modules/admin) with namespaced migrations and our own namespaced migrations.
In the app config we have this block:

'controllerMap' => [
    'migrate' => [
        'class' => 'yii\console\controllers\MigrateController',
        'migrationNamespaces' => ['app\migrations'],
        'migrationPath' => null, // disable all non-namespaced migrations
    ],
],

And applied migrations ordered by apply_time:

• app\migrations\M161210195701CreateUserTable
• app\migrations\M161210195702CreateProfileTable
• app\modules\admin\migrations\M161210195703CreateAccessTable
• app\modules\admin\migrations\M161210195704CreatePostTable
• app\migrations\M161210195705CreateRoleTable
• app\modules\admin\migrations\M161210195706AddSomeColumn

I expect the yii\console\controllers\MigrateController::getMigrationHistory() method, that's used by migrate/history and migrate/down commands, will filter the applied migrations by the migration namespaces.

For example:
./yii migrate/history (where migrationNamespaces = ['app\migrations'] from the app config) should return only migrations from the app\migrations namespace:

(datetime) app\migrations\M161210195701CreateUserTable
(datetime) app\migrations\M161210195702CreateProfileTable
(datetime) app\migrations\M161210195705CreateRoleTable

Whereas ./yii migrate/history --migrationNamespaces=app\modules\admin\migrations should return only migrations from the module namespace:

(datetime) app\modules\admin\migrations\M161210195703CreateAccessTable
(datetime) app\modules\admin\migrations\M161210195704CreatePostTable
(datetime) app\modules\admin\migrations\M161210195706AddSomeColumn

Isn't that the expected behavior?

[SilverFire]

Which Yii version do you use?

[yii-bot]

Thanks for posting in our issue tracker.
In order to properly assist you, we need additional information:

• When does the issue occur?
• What do you see?
• What was the expected result?
• Can you supply us with a stacktrace? (optional)
• Do you have exact code to reproduce it? Maybe a PHPUnit tests that fails? (optional)

Thanks!

This is an automated comment, triggered by adding the label status:need more info.

[djagya]

@SilverFire v2.0.11-dev

[djagya]

@SilverFire I can send a PR if the suggested behavior looks ok for you and other team members

[SilverFire]

The behavior does not look correct to me and could be enhanced.
Let's wait for @klimov-paul opinion

[spinitron]

To be clear, the migrations in each namespace need to be independent of each other for this to work properly. That's the use case I imagine. The module's migrations set up tables that are independent of the main app's tables and other modules.

[klimov-paul]

Filtering migration history is a risk prone as it may cause unexpected behavior.
Migration history is involved during down migration workflow. Filtering history with particular namespace will cause incorrect migration reverting order.
For example: assume we have following applied migrations:

• module\migrations\M1Init
• module\migrations\M2Improve
• app\migrations\M3UseModule

Where app\migrations\M3UseModule depends on tables created at module migrations.
If you filter migrations by namespace module\migrations\* and run down it will cause an error: most likely Integrity exception or silent database structure break.

If you wish migrations from different namespaces to be applied and tracked down fully separated you should configure multiple migration commands, which will use different namespaces and different migration history tables:

return [
    'controllerMap' => [
        'migrate-app' => [
            'class' => 'yii\console\controllers\MigrateController',
            'migrationNamespaces' => ['app\migrations']
            'migrationTable' => 'migration_app'
        ],
        'migrate-module' => [
            'class' => 'yii\console\controllers\MigrateController',
            'migrationNamespaces' => ['module\migrations']
            'migrationTable' => 'migration_module'
        ],
    ],
];