Tips for Fixing Ruby Migration Errors

When you are moving quickly, sometimes the migrations in your locally running app get tripped up. This may be due to something on your side or coordinating with your team. There are a number of possible not-fun reasons. Whatever the cause, you just want to get past it and continue writing code.

Here are some things I have learned to resolve Ruby migration errors involving duplicate columns.

Problem: Duplicate column error

You might get a message like this when you run your migration. The PG refers to the PostgreSQL database I’m using, but this can happen regardless of your database choic

rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::DuplicateColumn: ERROR:  column "stocksplitratio" of relation "tags" already exists

The problem here is that your migration will not run because those changes already exist in your schema, so you are stuck in a loop. You have to run the migration to be able to render your code locally, but you can’t run the migration because your app sees that those elements already exist.

Solution #1:

Comment out the offending part of the migrations and rerun, then uncomment them.

If you are sure your schema is correct (or if you have just manually copied it over from the source file in your GitHub repo), you can comment out the part of the migration files that are getting stuck, run your migration, then uncomment that code.

You need to include the top and bottom part of the migration file. Just comment out the middle, like this:

class AddMoreExpandedEntityFieldsToTags < ActiveRecord::Migration
def change
  change_table :tags do |t|
    # t.string :filingtype
    # t.string :quarter
    ... all your info here
    # t.string :accountingchangetype
  end
end
end

Then, rerun the migration.

rake db:migrate

Then, you will see something like this:

Changes to be committed:
 (use "git reset HEAD ..." to unstage)

       new file:   db/migrate/20160526221804_add_more_expanded_entity_fields_to_tags.rb
       new file:   db/migrate/20160530151904_add_stock_split_ratio_tag_info.rb

Changes not staged for commit:
 (use "git add ..." to update what will be committed)
 (use "git checkout -- ..." to discard changes in working directory)

       modified:   db/migrate/20160526221804_add_more_expanded_entity_fields_to_tags.rb
       modified:   db/migrate/20160530151904_add_stock_split_ratio_tag_info.rb

The migrations actually run, but without the offending pieces. Your app should now render locally.

Remember that you now need to uncomment the parts of those migrations, and then add and commit them back.

Solution #2 (not preferred):

Delete the offending migration files completely, confirm your schema is correct (or add in your correct schema manually from the GitHub source), run the migrations, then add your migrations back manually, exactly as they appeared before, in the same order.

If the first solution does not work for you, try this surgical approach. It is not recommended, because there are many ways to screw it up. But if you are desperate, here are the steps ...

First, manually delete the offending migrations from your local app version.

Then, rerun the migration.

Your app should now render locally.

But remember you need those migrations back in there!

So next, put the migrations back exactly as they were before.

Do this manually. Get the original migration files from your source repo in GitHub. You need to make sure they stay in the exact original order, since the order in the app is the order in which they are processed when you run a migration.

Note: When I do this, GitHub displays the migrations in the reverse chronological order from the order in my local app. This requires manually transposing the order to figure out where yours should be put back into your local version. (I use RubyMine; your IDE may display them differently.)

Now you wil be able to work on code and push your commits up safely so it will not impact your team. Good luck!