[Doctrine migrations] in-depth analysis of database migration components: installation and use

Scenario Analysis

In team development, each developer must manually record the changes to the database, which need to be collated on-line and the cost of operations is extremely high. And the synchronization of data structures between multiple developers is also a big problem. Doctrine Migrationscomponents to add database changes to the code and code together to version management, a good solution to the above problems.

Doctrine Migrationsis a Doctrine DBAL component-based data migration component. Integrated into mainstream frameworks such as Laravel,symfony. Can be divided into two ways to migrate, that is, version management mode and diff mode.

versioning : Write database changes into your code for version management. The Laravel framework is a version-managed pattern, and the default command line for migrating components is to support this pattern.

diff: Compare the existing database structure with the database structure in the code to perform the differential SQL to ensure consistency. ORM support is generally required, and the Symfony framework is a Doctrine2 data migration using ORM Tools plus a Doctrine DBAL diff method.

Instead of discussing the use of data migration components in an existing framework, this series focuses on how to use the migration components separately and how to integrate the data migration components into your own projects and customize them.

Installation

Composer installation

composer require doctrine/migrations ~1.8.0

This series is currently available in the latest version 1.8.1

Configuration

cannot be used directly after installation, but also requires component configuration and database configuration:

1. Build the migrations.php file under the root directory, configure the components:

php return [ ‘name‘ => ‘Doctrine Migrations‘, // 组件显示名称 ‘migrations_namespace‘ => ‘db\migrations‘, // 迁移类的命名空间 ‘table_name‘ => ‘migration_versions‘, // 迁移组件的表名 ‘migrations_directory‘ => ‘db/migrations‘, // 迁移类的文件夹 ];

See the official documentation for details of configuration parameters.

1. Root directory CV migrations-db.php file, configuration database information:

php return [ ‘driver‘ => ‘pdo_mysql‘, ‘host‘ => ‘localhost‘, ‘port‘ => 3306, ‘user‘ => ‘root‘, ‘password‘ => ‘1236‘, ‘dbname‘ => ‘migrations‘, ];

To this, the configuration required by the component has been completed.

Use

1. Run the following command in the vendor directory to generate the version migration class file.

bash ./vendor/bin/doctrine-migrations migrations:generate

The version20180608155932.php class file is generated under the Migration class directory/db/migrations, which is the class for writing to the migrated SQL, and the number after version is the current version number.

1. Override the up method for performing migration sql:

php public function up(Schema $schema): void { $table = $schema->createTable(‘test1‘); $table->addColumn(‘id‘, ‘integer‘)->setUnsigned(true)->setAutoincrement(true); $table->addColumn(‘name‘, ‘string‘)->setDefault(‘‘)->setLength(20); $table->setPrimaryKey([‘id‘]); }

This script is to generate a test1 table.

1. Override the Down method, which is used for version fallback, to undo the migration operation of the UP method:

php public function down(Schema $schema): void { if ($schema->hasTable(‘test1‘)) { $schema->dropTable(‘test1‘); } }

1. To perform a migration command:

bash ./vendor/bin/doctrine-migrations migrations:migrate

This succeeds in creating a version of the migration data. The migration class script can use $schema to manipulate database entities, or you can use the $this->addsql () method to write directly to the relevant SQL, detailing the official documentation for scripting details, but this is much more extensive.

Version Management

Since migration uses versioning, you can switch back and forth between multiple versions. The following are the relevant version switching commands:

./vendor/bin/doctrine-migrations migrations:migrate 20180608161758

This command restores to version 20180608161758, with a more convenient version alias, in addition to entering the specific version number directly:

• First: Fallback to the original version
• prev: Back to previous version
• Next: Migrating to the next version
• Latest: Migrating to the latest version (same as no version number effect)

Common commands

# 生成迁移脚本php migration.php migrations:generate# 执行迁移到最新版本php migration.php migrations:migrate# --dry-run是空转参数，只显示操作结果，不执行修改php migration.php migrations:migrate --dry-run# 不执行操作，只写入文件，对于生产环境需要手动验证并执行的场景有用php migration.php migrations:migrate --write-sql=file.sql# 查看详细信息php migration.php status

Conclusion

To this, we have learned the basic use of migrations components, but there are a few questions we need to solve:

1. A database configuration file is available in a generic project, how do I make a configuration file in a component common project?
2. Now the configuration files required for migrating components can only be in the root directory, how to make the configuration file more reasonable archive?
3. The command line is long and difficult to remember, how to use the command line simply?

In the next chapter, we will solve the above problems and make the components more personalized into our own projects.

In my code base you can view the detailed code of this article, welcome to star.

[Doctrine Migrations] Database migration components in-depth resolution one: installation and use