Converting Database Structure/Data in Rails

Question

This is kind of a follow up to this question: http://stackoverflow.com/questions/849897/can-rails-migrations-be-used-to-convert-data

If I'm working on a branch that, when it is re-integrated and released to production, will change the database schema quite drastically. What is the best way of ensuring that all the data in production gets converted to the new format?

A simple example would be, there is a numeric column which we want to change to text and do some conversion work on the data. Then we want to drop the old column.

I've been advised not to do any data manipulation in migrations but rather to create rake tasks for this. Is there a mechanism for ensuring rake tasks can be ran in order alongside migrations?

Right now, the only solution I can think of is to bundle up all the migrations that drop the defunct columns into a second collection. Run the first set of migrations that add the new tables. Run the rake tasks, then run the second set of migrations. This doesn't seem like an ideal solution to me and could easily go wrong.

Answer 1

Migrations are exactly for this kind of stuff. Converting data in the database for a new version of the application, with or without a schema change, should be a migration. This is guarantee that new changes are done in production before the new version of the application goes live.

When you're working in the branch, just create a new migration, which will create a new time stamped file. When you merge back into the release branch, the file will be just be copied over. Because of the timestamp, the migrations will (likely) execute in the correct order.

If the conversion you're doing, though, will continue to be executefrom time to time, then you should use a Rake task.