CODEWITHSUNDEEP
symfonydoctrine-ormmigration
testpresta
testpresta

Reputation: 449

Symfony2 doctrine2 migration script into table instead of file

I am working with doctrine:migrations:diff in order to prepare database evolutions.

This command creates files into app/DoctrineMigrations Thoses files contains sql commands in order to upgrade or downgrade database scructure.

I want to store those sql commands into the database itself. In fact, i have several instances of databases. If sql commands are store into files, it is a big problem.

I have read somewhere that DoctrineMigrations bundle can create a table called "migration_versions", but i do not manage to find where i have read this...

Upvotes: 0

Views: 252

Answers (1)

Marius Balčytis
Marius Balčytis

Reputation: 2651

I cannot really understand what you're trying to do.

Migrations are used when your code needs altered database structure. For example, a new table or a new column. These new requirements for a table or column comes from your newly written code, so it's only natural to place the migrations also as a code in your repository.

How and when would migrations even get to your database? How would you guarantee that migration is executed before the code changes, which use that new structure?

Generally, migrations are used in this way:

  • You develop your code, add new features, change existing ones. Your code needs changes to database.
  • You generate doctrine migration class, which contains needed SQL statements for your current database to get to the needed state.
  • You alter the class adding any more required SQL statements. For example, UPDATE statements to migrate your data, not only the structure.
  • You execute migration locally.
  • You test your code with database changes. If you need more changes, you either add new migration, or execute migration down, delete it and regenerate it. Never change the migration class, as you'll loose what's supposed to be in the database and what's not.
  • You commit your migration together with code that uses it.

Then comes the deployment part: - For each server, upload the code, clear and warm-up cache, run other installation scripts. Then run migrations. And only then switch to the new code.

This way your database is always in-sync with current code in the server that uses that database.

migration_versions database table is created automatically by doctrine migrations. It holds only the version numbers of migration classes - it's used for keeping track which migrations were already run and which was not.

This way when you run doctrine:migrations:migrate all not-yet-ran migrations are executed. This allows to migrate few commits at once, have several migrations in a commit etc.

Upvotes: 3

Related Questions