CODEWITHSUNDEEP
ruby-on-railsrubyheroku
botbot
botbot

Reputation: 7359

Heroku rake db:migrate

Heroku is telling me that there are migrations that haven't been run, when clearly they have been. It looks like it is behind one migration. How could I solve this problem.

When I run rake db:migrate it tells me rake aborted Mysql2::Error: Duplicate column name. I know these fields have already been created, also pretty sure that migration ran, as those fields don't exist in any other migration and rake db:migrate runs just fine on my local system.

How can I fix this? I think Heroku just didn't realize it already ran that migration. How can I tell it "you already ran migration xxx"?

Upvotes: 3

Views: 694

Answers (2)

DGM
DGM

Reputation: 26979

That probably means you ran it once, but it failed; table alterations in mysql are not transactional, so you can get left in a bad state. Some of the changes may have run, but not all of them.

The only thing you can do is determine which parts already ran, comment out those line in the migration, commit and push and run the migration, bypassing the parts that already ran.

Upvotes: 4

Robin Daugherty
Robin Daugherty

Reputation: 7524

If a migration is incompletely applied, do one of the following:

  • Use the dbconsole to undo the changes that were applied and then run the migration again, or
  • make the remaining schema changes manually using the dbconsole and then insert a record into the schema_migrations table.

Depend on what types of changes are in the migration script, you'll need to decide which of the above is easiest. If the changes already applied are destructive changes, such as dropping a column or table, you could recreate the column or table so that the migration will be able to run. If the remaining changes are simple to translate into SQL, then that might be easier.

Inserting a record into the schema_migrations table will allow the app to think that the migration was successfully applied. Do this only if you're absolutely satisfied that the migration changes were completely applied. It has one column, version, which will need to contain the numeric part of the migration filename.

http://api.rubyonrails.org/classes/ActiveRecord/Migration.html http://guides.rubyonrails.org/migrations.html

Finally, this is an example of why you should use Postgres instead of MySQL. Postgres is able to roll back (most) schema changes in a transaction, so you wouldn't be left with a half-applied migration.

Upvotes: 1

Related Questions