Archive for October, 2011

git, migrations and everything in between

Simultaneously working on multiple branches with git could be quite confusing at times. Very confusing.

Recently I found myself in a very strange situation: I changed some old migration file to suit a change of requirements in the application. After changing it and in order to apply the changes to the DB I ran

rake db:migrate:redo

Which should have performed rollback and migrate on the last migration.

What did I get in response you ask? A new, fresh shell prompt line and an unchanged DB. Not very informative of rake isn’t it?

Next step in investigating the mystery I’ve decided to let rake tell me what hurts him:

rake --trace db:rollback

This time the response was better, still not really indicating the problem:

** Invoke db:rollback (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:rollback
** Invoke db:schema:dump (first_time)
** Invoke environment
** Execute db:schema:dump

If that’s the same response you’re getting, most chances that you have migrated your DB on another git branch using migration X, and then switched back to your current branch, in which the migration file X does not exist.

What you should look for is the schema_migrations table on your DB, and compare it against your db/migrate/* files. The table lists the various versions of your DB and it should match the timestamps on your migration files. A mismatch between the two sets of data will reproduce the responses I got from rake.

The cleanest solution for this is to switch back to the old branch and rollback your DB to a common version with your current branch (you can perform multiple rollbacks with rake db:rollback STEP=n, where n is the number of consecutive rollbacks you’d like to perform),  then switch back to the branch you’re working on and viola! rake responds as expected again and you are free to migrate your DB up and down as you wish.

, , ,

Leave a comment

Our version of mysql backup using rake

Leave a comment