Added support for specifying aliases for migrationNamespaces

[cebe]

This is used to specify pathes to migrations that do not have
namespaces.

While not directly supported by the migration command provided by the
framework, these migrations exist in a lot of extensions because custom implementations
of migration controllers out of the framework were using this approach
to load multiple migrations from multiple paths.

Even the framework itself currently ships non-namespaced migrations:

• https://github.com/yiisoft/yii2/blob/17a1d91e4a517f4f15dce973bf3c50dd939dce63/framework/rbac/migrations/m140506_102106_rbac_init.php
• https://github.com/yiisoft/yii2/blob/17a1d91e4a517f4f15dce973bf3c50dd939dce63/framework/caching/migrations/m150909_153426_cache_init.php
• https://github.com/yiisoft/yii2/blob/17a1d91e4a517f4f15dce973bf3c50dd939dce63/framework/log/migrations/m141106_185632_log_init.php

This change allows existing applications to adopt the new namespace-based approach
while keeping existing migrations. While it would be possible to add
namespaces to migrations in the application itself, it is not easily possible
to add namespaces to migrations that come from external sources like
extensions.

related discussion in #13359 and #13356.

this replaces #13359

• I will add some tests to verify behavior later.

[yii-bot]

Thank you for putting effort in the improvement of the Yii framework.
We have reviewed your pull request.

In order for the framework and your solution to remain stable in the future, we have a unit test requirement in place. Therefore we can only accept your pull request if it is covered by unit tests.

Could you add these please?

Thanks!

P.S. If you have any questions about the creation of unit tests? Don't hesitate to ask for support. More information about unit tests

This is an automated comment, triggered by adding the label pr:request for unit tests.

[klimov-paul]

I am against such change as it mixing up different terms 'namespace' and 'path alias'.

[cebe]

@klimov-paul I partly agree with that. We could alternatively add another property or make migrationPath accept an array.

[dynasource]

I agree on having this in a separate property called $migrationPaths

[schmunk42]

Works nicely with this rather complex setup:

    'controllerMap' => [
        // Yii 2.0 default migrate controller
        'dev:migrate' => [
            'class' => '\yii\console\controllers\MigrateController',
            'migrationPath' => [
                getenv('APP_MIGRATION_LOOKUP'),
                '@yii/rbac/migrations',
                '@yii/web/migrations',
                '@bedezign/yii2/audit/migrations',
                '@dektrium/user/migrations',
                '@hrzg/widget/migrations',
                '@dmstr/modules/contact/migrations',
                '@dmstr/modules/pages/migrations',
                '@dmstr/modules/redirect/migrations',
                '@vendor/lajax/yii2-translate-manager/migrations',
                '@vendor/pheme/yii2-settings/migrations',
                '@vendor/dmstr/yii2-prototype-module/src/migrations',
            ],
        ],

End of output:

*** applied m170320_133511_auth_items (time: 0.006s)

*** applying m170322_204909_update_timestamp_columns
    > alter column created_at in table dmstr_page to datetime ... done (time: 0.165s)
    > alter column updated_at in table dmstr_page to datetime ... done (time: 0.184s)
*** applied m170322_204909_update_timestamp_columns (time: 0.360s)

*** applying m170327_120427_update_icon_column
    > update dmstr_page ... done (time: 0.004s)
*** applied m170327_120427_update_icon_column (time: 0.010s)

*** applying m170328_111312_init
    > create table {{%dmstr_contact_log}} ... done (time: 0.053s)
*** applied m170328_111312_init (time: 0.057s)


60 migrations were applied.

Migrated up successfully.

---

Also work via the command line:

$ yii dev:migrate --migrationPath=@app/migrations/demo-data,@app/migrations
Yii Migration Tool (based on Yii v2.0.12-dev)

Total 1 new migration to be applied:
        m150917_193929_rbac

Apply the above migration? (yes|no) [no]:

If the default is wrapped in [] - will add a comment in the code.

[schmunk42]

I had to wrap this in brackets, so the CLI can recognize it as an array

public $migrationPath = ['@app/migrations'];

[schmunk42]

At the moment there is migrationPath and migrationNamespaces, which is a bit confusing due to mixing singular and plural.

What's about having a singular and plural form for both - background is that you could use the singular form to inject just a single folder, while having the basic configuration still available in the plural form. So you do not have to override it with all values, plus the one you want to inject.

We use this workflow i.e. for demo-data or test-data.

[cebe]

The naming in plural and singluar has historical reason, in oder to keep BC we can not change it.
Adding more properties sounds complicated to me. I think it is fine as is.

[schmunk42]

Basically I am fine with this, just a more general thing from my side to add: I'd find it helpful, if I could see in advance, if a property of method accepts an alias or requires a path.

So having migrationAliases along with migrationPath in 2.0 and deprecate the latter in 2.1.

[edit]

I know that migrationPath also accepts an alias, but AFAIR not all framework methods/props with ...path do.

[cebe]

I know that migrationPath also accepts an alias, but AFAIR not all framework methods/props with ...path do.

a general rule for this is that all parts that receive input via console or configuration accept an alias. Methods that are only called via code, e.g. FileHelper do not.