strapyourself.in and flouri.sh
Writing data migrations in rails
Using ActiveRecord can be tricky, here's how
Data migrations are a major headache in every rails project I've worked on. Developers typically write straight SQL migrations which take much longer to create and test, or they use ActiveRecord and run into problems. I recent wrote a data migration which took 7 existing tables and compressed them into 4. Some of the new 4 had the same names as the existing models, so I finally figured out how to do this safely with ActiveRecord. Here's my advice:
- When changing the schema of an existing set of tables, create new tables and then rename them.
- Include active record fragments inside the migration class at the top of your migrations.
- Put your data migrations inside transactions.
- Make your data migrations completely reversible (which is a lot easier when you follow the first rule)
Here's an example of an ActiveRecord class fragment at the top of a migration:
class MarkPrimaryBits < ActiveRecord::Migration class LessonVersion < ActiveRecord::Base belongs_to :lesson end class Lesson < ActiveRecord::Base has_many :lesson_versions end def self.up ...
By putting the Lesson and LessonVersion classes at the top of the migration, I'm allowing myself to use those classes inside my migration and be completely independent of any changes made to the real model from then on (including the deletion of the class itself). Furthermore, I can have another migration which uses those same class names with completely different meanings and they won't conflict with each other.
Sorry, comments are closed for this article.