Tips for Fixing Ruby Migration Errors
Submitted about 5 years Ago
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, for a number of reasons. This is the worst! Whatever the cause, you just want to get past it and continue writing code.
Here are some tips 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 choice:
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.
Comment out offending part of migrations and rerun, then uncomment them.
If you are sure your schema is correct (or if you have now just manually copied it over from the source file in your github repo), you can comment out part of the migration files that are getting this 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.
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 you now need to uncomment the parts of those migrations and then add and commit those back.
Solution #2 (not preferred):
Delete the offending migration files completely, confirm your schema is correct (or add in your correct schema manually from 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 since 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 in there 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 that you manually transpose 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 are able to work on code and push your commits up safely so it will not impact your team. Good luck!