Imagine you have a table that has 5 columns, and you need to split this into two tables, because in your iterative process, your application has increased in complexity.

Should migrations change the data, as well? After all, you are dropping two columns and moving them to another table, and these two tables now probably need a foreign key to connect them, too.

What has me confused here is that as far as I know, migrations are only responsible for changing the structure of the database. It is all fine on a development database, but what would you do when you want to push this onto a live database?

1 Answer 1


Migrations should change the data when needed - otherwise they don't fulfill their purpose of taking a database that works for an old version of the application and making it work for newer versions. Migrations are also the best place to do this, because you can make assumptions on the database's structure before and after the migration is run.

One thing to keep in mind though - if you plan to use the ORM for these changes, make sure you are using classes fit for the post-migration state of the database, not the ones the application is using, because the ones the application is using target the latests version of the database schema, not the one the migration will be running. If your ORM does not allow it don't use it in the migration - use raw SQL instead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.