Migration (--migrationPath)

[ghost]

hi all, sorry for any inconvenience
when making a migration indicating the migrationPath, for example:

$./yii migrate --migrationPath=modules/foo/migrations

yii does not save the migration path used in migration. So when I run the command down, I have to specify the migrationPath for each migration or grup. but when many migrations, this becomes a problem.

when i run the command without the parameter migrationPath in a migration that is not in the default directory y get the exception failed to open stream: No such file or directory' obviously

with many migrations and modules do this is difficult, I think yii should store the migrationPath used for each migration.

something like change the migration table to :

CREATE TABLE migration (
        version varchar(180) PRIMARY KEY,
        path varchar(x),
        apply_time integer,
  )

if there is a way to do it, let me note. thk team :D

[samdark]

There's currently no way doing it automatically.

[mdmunir]

Alternative https://github.com/deesoft/yii2-console
Add your migration paths as application params

// params.php
return [
    'dee.migration.path' => [
        '@yii/rbac/migrations',
        '@mdm/autonumber/migrations',
        '@mdm/upload/migrations',
    ]
];

[ghost]

modify the database would be the best way? and change the getMigrationHistory() (in yii\console\controllers\MigrationController) to modify the basePath Attribute based on the value of the database

[pana1990]

maybe "db" should be include too. it is useful when i have two or more dbms.

@samdark @mubushi @mdmunir what do you think about it? i can create pull request for this issue.

[samdark]

I think the best way to solve it is to create bash script that runs a couple of commands specifying necessary --migrationPath. Are there any pros implementing it at console command level?

[pana1990]

if you want to use " migrate/redo all or migrate/down all"? bash script not works for this case use.

[samdark]

Why?

[pana1990]

how @mubushi said

"when i run the command without the parameter migrationPath in a migration that is not in the default directory y get the exception failed to open stream: No such file or directory' obviously "

if you want to run migrate/up you have create bash script, if you want to run migrate/down you have create another bash script again.

when you have many migrations and modules do this is difficult, i think to this feature should be include out of the box.

[samdark]

Not really another. It's about adding more lines to existing migrate_down.sh or migrate_up.sh. Same amount of lines as would end up in config, I guess...

[pana1990]

when you have new migration you have to include it in migrate_down.sh and migrate_up.sh, it is little troublesome. I think to this feature should be handle framework.

it simplify development.

[samdark]

Not when you have new migration but when you have new path for migrations such as new module. That's the same with configs — with each new module you have to add another path to config file.

[pana1990]

sorry, i dont understand.

if i want to "migrate/redo all" for example how do you do it?

in the following case how do you do it?

 1º migration default path
 2º  '' module user path
 3º  '' default path
 4º  '' module rbac path

[samdark]

Yes:

./yii migrate/redo all
./yii migrate/redo all --migrationPath=module1/foo/migrations
./yii migrate/redo all --migrationPath=module2/foo/migrations
./yii migrate/redo all --migrationPath=module3/foo/migrations

[pana1990]

@samdark I think you dont understand me.

For example i run the following steps :

1º i create migration test1 in default path and run migrate
2º i run migration in rbac module
3º i create second migration test2 in default path and run migrate
4º i run migration in user module

migration history is :

when i run yii migrate/redo it throws an exception obviusly :

[klimov-paul]

The most proper way to solve such problem would be usage of the namespaces for migrations insteand of paths.
In general we can determine the file path from the namespace and thus find all new migrations. While storing full namespaced class names in the migration table allow to revert any migration at any moment no matter where it is declared.
This would be a nice solutions for extension building and issues like #8202.

[samdark]

@pana1990 then you commit all these migrations into repository and another developer who's in your team is trying to apply them. How would they do that?

[samdark]

@klimov-paul yes, that could solve the issue.

[pana1990]

@samdark mmm, it's truth. In rails resolve this issue with schema dump. For more details http://guides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you

[ghost]

hi guys, @klimov-paul, @samdark , @pana1990 , sorry for the inactivity.
i think the approach:

usage of the namespaces for migrations instead of paths.

is the better and simple way to solve this issue.

[nkostadinov]

+1 for @klimov-paul solution. Migrations should use namespaces at least to be consistent. Working with many modules with migrations can be really cumbersome.

[mdmunir]

A simple way to solve this problem and still keep BC is add new property to migration controller e.g migrationLookup. So, instead of use --migrationPath=@newPath we add new path to that propterty.
Everytime we need new path, we can add it to migrationLookup

'controllerMap' => [
    'migrate' => [
        'class' => 'yii\console\controllers\MigrateController',
        'migrationLookup' => [
            '@yii/rbac/migrations',
            '@another/ext/migrations',
        ],
    ]
]

Then, we just change simple code in MigrateController::getMigrationHistory().

PS: We dont need to change table schema.

[ghost]

hi @mdmunir, the database schema does not change, just the whole class name (all namespace) in the "version" field in the table would be stored.

[mdmunir]

@mubushi And what about previous migration file that not in the namespaced class? Is it still compatible?

[ghost]

@mdmunir I believe that the above files are supported,
eg up migration
./yii migrate --migrationPath = @ path / to / migrations
and the database could keep
path \ to \ Migrations \ migrationName

during migrate / down yii find the file, even if does not have namespace as said @klimov-paul

In general we can determine the file path from the namespace and thus find all new migrations. While storing full namespaced class names in the migration table allow to revert any migration at any moment no matter where it is declared.

and solves the problem of locating migration in turning back

. but what you propose I like, because it would not specify the migration path migrate / up and would not have to make many changes XD.

[Faryshta]

I think the best to solved this is to use namespaces and a $depends field like it was proposed in #8202

namespace Acme\Sihpments\migrations;

use yii\db\Migration;

class ShipmentLog extends Migration
{
    $depends = [
         'Acme\Shipments\migration\Shipment'
    ];
}

Then use two tables in the migration table to handle the history of migrations save the full namespaced class

[klimov-paul]

Solution proposed at #12511

[klimov-paul]

Resolved by commit 8aa0e85

[mdmunir]

@klimov-paul are the solution backward compatible?
I mean, when i do migrate/up in the past from several directory, then i want migrate/down all, it is going ok?

[klimov-paul]

yes, it should be

[mdmunir]

@klimov-paul
When migrate/up

When migrate/down

[klimov-paul]

The file path will NOT be saved - it was never promised.
You can put your migrations under the namespace and they will be saved into the history with thier namespace. You can specify several namespaces, but not several file paths.

[mdmunir]

That what i mean. The migration does not remember migration path.
Namespace solution only fix next migration but not previous problem.

[klimov-paul]

Several migration path will not be supported - this decision is final.
You may update your project to make migration namespaced and manually update the content of the migration table (you can use migration mark command for that) if it is crucial for you.