0

I accidentally deleted my production database on heroku cedar stack several months ago. I tried to recreate the db via heroku run rake db:migrate, but something was wrong with my migrations and it failed. I then installed taps and did a heroku db:push and all was right with the world.

Can I now use heroku run rake db:migrate after running local migrations to update the production database, or am I forever tied to taps and heroku db:push?

Perhaps a better way to ask this question: will heroku run rake db:migrate go through all of my migrations (and likely fail), or will it only go through migrations that have occurred since the last heroku db:push?

tomb
  • 1,374
  • 1
  • 13
  • 23

1 Answers1

0

Take a look at the schema_migrations table in your database. This is what Rails uses to determine which migrations to run. It has a single column containing each migration version Rails has applied to your application. For example, I have the following file in db/migrate:

  • 20110415064108_create_users.rb

20110415064108 is listed as a row in my schema_migrations table. The same goes for every other migration file in db/migrate that existed since I last ran rake db:migrate.

Assuming taps (which I know nothing about) pushed this schema_migraions table in its entirety to production, you should be able to create new migrations and run them with rake db:migrate in production without trouble (only those newly created migrations will be applied, since their version #s are the only ones missing from the production schema_migrations table).

deefour
  • 34,974
  • 7
  • 97
  • 90
  • Thanks for the tip about the schema_migrations table. I just ran a migration, pushed it to production, and heroku run rake db:migrate worked. Thanks. – tomb Aug 04 '12 at 15:31