Download the PHP package bizley/migration without Composer

Yii 2 Migration

Migration Creator And Updater

In a perfect world you prepare migration files for your database first so you can run it when ready. But since this is not a perfect world, sometimes you start with a database already set - with this package you can easily create a migration file based on your DB schema with one console command.

Furthermore, when your DB is updated later on you can generate a migration file updating the schema to the current state. The package is comparing it with the migration history:

1. History of applied migrations is scanned to gather all modifications made to the table.
2. Virtual table schema is prepared and compared with the current table schema.
3. Differences are generated as an update migration.
4. In case of the migration history not keeping information about the table, a creating migration is generated.

Installation

Run console command

Or add the package to your composer.json file:

then run composer update.

Configuration

Add the following in your configuration file (preferably console configuration file):

Additional options are available as following (with their default values):

Usage

The following console command are available (assuming you named the controller migration like in the example above):

• List all the tables in the database:

  or

• Generate migration to create DB table table_name:

• Generate migration to update DB table table_name:

  To generate migrations for all the tables in the database at once (except the excluded ones) use asterisk (*):

  You can generate multiple migrations for many tables at once by separating the names with comma:

  You can provide an asterisk as a part of table name to use all tables matching the pattern:

  Creating multiple table migrations at once forces the proper migration order based on the presence of the foreign keys. When tables are cross-referenced the additional foreign keys migration is generated at the end of default generation.

• Extract SQL statements of migration migration_name (UP) New in 4.4.0:

• Extract SQL statements of migration migration_name (DOWN) New in 4.4.0:

Command line parameters

[1] Remember that with different database types, general column schemas may be generated with different length.

MySQL examples:

Column varchar(255)
generalSchema=false: $this->string(255)
generalSchema=true: $this->string()

Column int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY
generalSchema=false: $this->integer(11)->notNull()->append('AUTO_INCREMENT PRIMARY KEY')
generalSchema=true: $this->primaryKey()

When column size is different from DBMS' default, it's kept:
Column varchar(45)
generalSchema=false: $this->string(45)
generalSchema=true: $this->string(45)

[2] Here you can place the migrations containing actions that cannot be covered by the extractor, i.e. when there is a migration setting the RBAC hierarchy with the authManager component. Such actions should be kept in a separated migration and placed on this list to prevent them from being run during the extraction process.

[3] This mode allows using a raw SQL column definition for the migration updater (i.e. ['column' => 'varchar(255)'] instead of ['column' => $this->string()]). Since the generating process in this mode depends on the individual DBMS syntax the results might not be correct. All help improving this mode is more than welcome.

Important information about RENAMING tables or columns

When you rename a table or a column, remember to generate appropriate migration manually, otherwise this extension will not generate an updating migration (in case of the table) or will generate a migration with the command to drop the original column and add a renamed one (in case of the column). This is happening because yii2-migration can only compare two states of the table without the knowledge of how one state turned into another. While the very result of the migration renaming the column and the one dropping it and adding another is the same in terms of structure, the latter makes you lose data.

Once you add a renaming migration to the history, it's being tracked by the extension.

Migrating from v2 or v3 to v4

See Migrating to version 4.0 section.

Notes

This extension should work with all database types supported in Yii 2 core:

• CUBRID (9.3.x and higher)
• MS SQL Server (2008 and above)
• MySQL (4.1.x, 5.x, 8.x)
• Oracle
• PostgreSQL (9.x and above)
• SQLite (2/3)

Only history of the migrations extending yii\db\Migration class can be properly scanned, and only changes applied with default yii\db\Migration methods can be recognised (except for execute(), addCommentOnTable(), and dropCommentFromTable() methods). Changes made to the table's data (like insert(), upsert(), delete(), truncate(), etc.) are not tracked.

Updating migrations process requires for the methods createTable(), addColumn(), and alterColumn() to provide changes in columns definition in the form of an instance of yii\db\ColumnSchemaBuilder (like $this->string() instead of 'varchar(255)').

The new 4.4.0 feature with extracting SQL statements from the existing migration supports all methods available in yii\db\Migration.

Tests

Tests for MySQL, PostgreSQL, and SQLite are provided. Database configuration is stored in tests/config.php (you can override it by creating config.local.php file there).
Docker Compose file for setting up the databases is stored in tests/docker.

Previous versions

These versions are not developed anymore but still available for all poor souls that are stuck with EOL PHP. Some of the newest features may not be available there.