I need to write a data change migration (splitting data from one table into another table, and removing redundant columns). Given that the product is in production now, I must have a test that proves my migration works. So, how do I test my migration? I need to pull the database up to the point prior to the migration, setup some data, run the migration, then see that the results are correct. This requires that all previous migrations run fine, which is currently not the case (some old pure-data migrations are of course failing hard).

I’ve been searching, talking with co-workers, I just don’t know what the solution to this is. I’ve personally always had the mindset that all migrations should be up- and down-able for this reason. Any one have suggestions here?

One thing I will NEVER do is re-run a migration. A migration is a run-once and once only script (per database) and therefore I have no problem with it updating any of my database state whether schema or data.

Sometimes changing a schema requires setting data to a value such as adding a column and setting a ‘default’ value based on existing data. A migration allows that to be done inline so that migrations can run one after each other without having to stop to run a rake task.

To clarify my run-once statement, once a database is in production, there is no way I’m dropping and re-creating with migrations. It’s live and must stay live so backups become the order of the day there.

I put migrations into three categories. Structural changes (add/remove tables/columns, etc.), static data (a zip code to lat/long conversion table), and data (static or dynamic) changes (populate a new join table between users and topics).

Structural changes are what migrations are great at. Use it and prosper. (schema.rb is unfortunately usually shite in a big team in my experience, mainly due to conflicts, and its ever-changing nature.)

For static data, I have not yet found a good solution for bulk loading large amounts of static data into a newly created database, especially a test database (fixtures don’t cut it for this stuff). Rails just isn’t built for that, and it’s frustrating sometimes. You end up in twisty little maze of implementations, all different.

Data changes are trouble, and I recommend against them as well. You have two basic choices, either use the model (slow and harms refactorability) or direct SQL which bypasses your validations, so can lead to subtle data errors.

*I* feel #14 should be NEVER use models in your migrations. If you find yourself tempted to use models in your migrations, you have clear evidence that you need a rake task. A one-off rake task, perhaps, but a rake task.

I’ve probably had a dozen models that I’ve refactored away over the years that broke somebody’s migration, and the only option was to go back and change their migration, which feels dirty for a reason.

That said, I also believe that a fresh development database should always be creatable from the migrations and that you should set up CC.rb to do a migrate to create its databases.

A great back and forth related to this is on this very site at: http://www.pathf.com/blogs/2008/07/resolved-should-schemarb-be-included-in-your-source-control/

– Morgan