A team of developers pretty often bumps into a problem when they need to save database history and update it during the development process without loss of existing data.

A lot of people create a history file, which they keep in the repository and each developer during the work process saves there commands of file updates. However this way is inconvenient for work in a big team, because members of the team get to know it’s high time they updated their copy of the base when the system has already returned an error.

Most of ORM libraries currently support migration mechanism. The article gives a brief overview of migration by means of Doctrine Library connected with Symphony framework.

Doctrine consists of a class set usable for migration creation.

Migration class is a child of Doctrine Migration Base class, which includes a set of methods for database tables structure updates. Doctrine allows generating migration classes automatically for its following use during the database structure update. Moreover developer has an opportunity either to migrate to a certain version or to roll back the tables structure updates.

Let’s try to illustrate migration mechanism by means of example.

There’s a project where configuration file is already defined, it keeps database tables structure and the models have already been generated.

After a time some changes have to be made to the existing tables as well as new ones have to be created. A developer changes file schema.yml, changes tables’ configuration and adds new ones.

Next instead of starting a command, which would create classes of our models we first of all generate migration classes.

php symfony doctrine:generate-migrations-diff –

Doctrine will compare our models structure (the ones we have not updated yet) with the updated file schema.yml, define differences and create classes, which will contain methods for creation of new fields and tables or for index updates.

Afterwards we will be able to find migration classes in the directory lib/migration/doctrine. Every new migration class has its own index. When you use migration mechanism for the first time, table called migration_version will be automatically created in the base. The table will keep version of database.

Now we can apply migration files and refresh our database.

php symfony doctrine:migrate [version].

Option “version” is migration number; we do not have to point out this option if we want to apply all database updates.

Later on we can create our models, forms and filters again.

php symfony doctrine:build-model

php symfony doctrine:build-form

php symfony doctrine:build-filter

We can add migration classes to repository, so when other developers update their projects copies, they will get these classes and it will be enough for them to perform a command

php symfony doctrine: migrate , in order to renew their copies of databases.

One should remember that migrations not always update data; there is also a risk to lose data during such a database update. I personally faced a problem of such kind,- I renamed a field in a table. Created migration classes, deleted existing field and created a new one with the new name instead, this way I could have lost all the data, kept in this field. That is why, the best way is to check the code of migration classes you generated and understand what they do before you use them.

Links:

http://www.doctrine-project.org/projects/orm/1.2/docs/manual/migrations/en

http://www.symfony-project.org/doctrine/1_2/en/07-Migrations

Andrew Z., PHP Department