Question

I have a pretty old migration on a legacy app by a friend that contains this snippet:

class MakeChangesToProductionDbToMatchWhatItShouldBe < ActiveRecord::Migration
  def self.up

# For some reason ActiveRecord::Base.connection.tables.sort().each blows up
    ['adjustments',
    'accounts',
     ...## more rows of classes here ###...
    'product_types'].each do |table|
      t = table.singularize.camelize.constantize.new
      if t.attributes.include?('created_at')
        change_column( table.to_sym, :created_at, :datetime,  :null => false ) rescue puts      "#{table} doesnt have created_at"
      end
      if t.attributes.include?('updated_at')
        change_column( table.to_sym, :updated_at, :datetime,  :null => false ) rescue puts "#{table} doesnt have updated_at"
      end
    end

This old migration is now conflicting with a new migration I wrote to remove two of the tables mentioned in this long list, which is now causing any deployment to error upon rake db:migrate.

What’s the correct kind of migration or down action to write to address this migration and get db:migrate working again?

Answer 1

There are a few different best practices that can help, but at the end of the day there’s no good way to always upgrade a database from an arbitrary point without stepping through the codebase along as you run migrations (speaking of which, why is there not already a rake task to do this?).

1. Always include a migration-namespaced copy of the models you’re working on. Example below.
2. When building a database from scratch, do not run migrations…use db:schema:load which will re-create the last snapshot of the database.
3. Don’t give your migrations ridiculous and aggression fueled titles like MakeChangesToProductionDbToMatchWhatItShouldBe.
4. Avoid making assumptions, when writing migrations, about the environment they will be run in. This includes specifying table names, database drivers, environment variables, etc.
5. Write down actions when you write up actions whenever a down action is feasible. It’s usually much easier (especially on esoteric or complex migrations) when the series of transformations is fresh in your head.

For this specific case, there’s an argument to be made for declaring “Migration Bankruptcy” — clearing out some or all existing migrations (or refactoring and coalescing into a new one) to achieve the desired database state. When you do this you are no longer backwards compatible so it is not to be taken lightly, but there are times it is the appropriate move.