If your application uses separate databases such as maps and analytics, you can organize their migrations
into isolated sets. Each set has its own migration directory and a separate migration history table in its database,
so migrations applied to one set do not affect the recorded status of migrations in another. Use --db to work with
one set, or apply migrations to all sets with a single command.
Your existing database is named default. Give each additional database a name, such as maps or analytics, and a
directory for its migrations. Define default in the same way when using named sets, with its own connection,
migration directory, and history table. Alternatively, keep your existing configuration for default and configure only
the additional sets. Choose one form for default; do not configure it in both places. Create the directories before generating migrations:
config/migrations/default/
config/migrations/maps/
config/migrations/analytics/
Follow the configuration instructions for your application:
The following examples use the standalone executable.
To create a migration in the maps directory:
./vendor/bin/yii-db-migration migrate:create create_places --db=mapsEdit the generated file with your migration operations as usual. When you apply it with --db=maps, those operations
run against the maps database.
Without --db, migrate:create creates the file in the default database's migration directory.
Apply pending migrations to maps only:
./vendor/bin/yii-db-migration migrate:up --db=mapsTo apply pending migrations to all configured databases:
./vendor/bin/yii-db-migration migrate:upThe default database runs first, followed by the additional databases in configuration order. If analytics needs tables
or data created by maps, configure maps before analytics.
You confirm migrations separately for each database. Add --force-yes to skip these prompts during deployment.
To apply at most two migrations per database:
./vendor/bin/yii-db-migration migrate:up --limit=2If a migration fails, execution stops before proceeding to later databases. Changes already applied to earlier databases remain. Fix the failing migration and run the command again; migrations recorded as applied are skipped.
When selecting migration files with --path or --namespace, also specify --db if you have multiple databases:
./vendor/bin/yii-db-migration migrate:up --db=analytics --namespace='App\Migrations\Analytics'This requirement also applies to migrate:new, so the selected files are checked against one database's history.
View pending migrations or applied migrations for maps:
./vendor/bin/yii-db-migration migrate:new --db=maps
./vendor/bin/yii-db-migration migrate:history --db=mapsOmit --db to view all configured databases. Results are grouped by database. The command succeeds if at least one
database has migrations to show, and returns a failure exit code if all results are empty. An error stops execution even
if an earlier database had results. Use --all to show the complete list or --limit=5 to show up to five migrations per
database.
History is stored in each database's own migration table, using its configured table prefix. If you configure multiple
names for the same physical database and want independent histories, give each a different historyTable value.
Revert the last maps migration:
./vendor/bin/yii-db-migration migrate:down --db=mapsRevert and apply the last maps migration again:
./vendor/bin/yii-db-migration migrate:redo --db=mapsWhen multiple databases are configured, both commands require --db. Use --db=default to select the default database.
With only one database configured, you can continue to omit the option.
Use migrate:mark to record migrations without executing them. With multiple databases, --db is required:
./vendor/bin/yii-db-migration migrate:mark 'App\Migrations\Maps\M260101000002CreateIndex' --db=mapsSee Modifying migration history for target selection and resetting history.