Data massaging in migrations and errors after refactoring 4

Posted by Tim Connor Thu, 22 Mar 2007 16:43:00 GMT

ActiveRecord migrations are a powerful tool for handling your database schema changes. Not only that, but you can run any AR code in them to tweak that data itself while migrating to the new structure, such as.

class AddUpdatedAtToReport < ActiveRecord::Migration
  def self.up
    add_column :fishing_reports, :updated_at, :datetime
    FishingReport.find(:all).each do |r|
      r.updated_at =
  def self.down
    remove_column :fishing_reports, :updated_at

Unfortunately this can lead to the migration becoming not only obselete but outright incompatible later, throwing errors. For instance, if you later refactor that model out of existence, the migration will fail, because there is no model to match FishingReport. I suspect there could be some future proofing done, by checking for the existence of the class, but one can easily imagine refactorings that wouldn’t be so easily guarded against.

I suppose that could be an excuse for more testing: migration testing. In fact, after using typo for a while, i think migration testing should maybe be a recommended paractice for any publically distributed Rails app.


Leave a comment

  1. Avatar
    Yossef 3 days later:

    The fact that models and migrations can be out of sync is why it’s recommended to include definitions of the models you’re using in the migrations itself. Nothing big, just something on the order of class FishingReport < ActiveRecord::Base; end to give a shell of functionality. This saves you from some problems, but unfortunately doesn’t let you use any special logic unless you’re willing to become positively WET and include the logic in both your actual model and your migration placeholder model.

    You can see examples of this in many Typo migrations.

  2. Avatar
    Tim Connor 3 days later:

    Ah, thanks for the tip Yossef. I was also thinking of wrapping it in a check for the existence of the model – since if the model class no longer exists then we probably don’t need to run a modification on the data.

    I do kinda think that full tests of the migrations would help either way, because either way I can think of ways you could break it.

    Amusingly enough, Typo is actually one of the places I’ve had problems with this before.

  3. Avatar
    Yossef 3 days later:

    The check could work in a way. Migrations can be weird in that sense because they let you change your database in a way that could be incompatible with your application. There are cases where you really need to have the correct revision of the source or else all is lost. Or, like you said, you could have tests.

    A little off-topic but still speaking of Typo, I’ve been using your typo-permalink-with-id plugin with success until I tried to upgrade to Typo 4.1. Now the article observer doesn’t do anything when creating an article through the web admin. It does change the permalink if I create an article from the Rails console.

    I noticed your permalinks recently stopped having IDs at the beginning. Did you also recently switch to Typo 4.1?

  4. Avatar
    Tim Connor 4 days later:

    Ya, it plum broke when typo moved to 4.1, and I hadn’t bother fixing it, because I had no idea nobody was using it. I seem to recall they moved a method into protected space that I needed or something. I was considering scrapping the approach and submitting a patch to make the “post not found” page do something useful, like listing posts from the same day. But know that I know someone aside from me was using it I’ll take another look.