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?
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.rb20110415064108 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).