CODEWITHSUNDEEP
symfonydoctrinedatabase-migration
nnikolay
nnikolay

Reputation: 1761

Doctrine migrations start in the middle of the project

I am working with Symfony and Doctrine. In the middle of the project I need to implement the Doctrine migrations, because the DB changes were too much and I need a better way to handle it. How is the best way to start with the migrations, when there is already data on prod and it need to stay there and not to be touched?

My plan will be:

On my test system

In this way, I have all the structures from my entities, but I will not destroy my live data.

What do you thing?

Upvotes: 4

Views: 1702

Answers (2)

Daniel L
Daniel L

Reputation: 632

Old thread here, but what I do in cases like this:

  1. Backup dev database (structure and data, but with table create statements protected with checking so they are only created if they don’t already exist)
  2. Drop all tables so the database is empty
  3. Generate migration (since database is empty, the generated migration will constitute all commands necessary to generate your entire schema)
  4. Run migration you just generated to build schema
  5. Import test data from your dump

That puts you right back where you started but with an initial migration that can build your schema from nothing.

Upvotes: 1

Matías Navarro Carter
Matías Navarro Carter

Reputation: 1828

If there is already some data on production, then your best take is to do a make:migration or doc:mig:diff from the current schema state. That will generate only the necessary sql that will update the new changes, but nothing else. Your first migration version will countain only the sql to update from the current state, and not from the beginning of times.

And also, once you have adopted this, you have to do every database modification under migrations. For example, if you need to add a non-nullable field, you usually add the new field with not null, then fill all the rows of that field with a default or calculated one, and then alter the table to make the field not nullable. Migrations will generate some boilerplate code to make your life easier, but it also requires a lot of care from the development team. Always test them first in a database that you can get rid of. And you will run into FK constraints and lots of other issues, but basically you have to solve them doing SQL.

Upvotes: 3

Related Questions