'rake db:migrate:redo' fails to update schema.rb

I wasted a fair bit of time today trying to figure out why when my specs didn't have the latest changes I'd made to the schema (and were failing as a result). Finally I tracked it down to this bug.

As a workaround, you can always do rake db:migrate:redo; rake db:schema:dump... but who wants to do that? So I decided to investigate a little further...

If you run rake db:schema:dump --trace you will notice that although both db:rollback and db:migrate invoke db:schema:dump, only the first "invoke" results in an **Execute** db:schema:dump.

** Invoke db:migrate:redo (first_time)
** 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
** Invoke db:migrate (first_time)
** Invoke environment
** Execute db:migrate
** Invoke db:schema:dump
** Execute db:migrate:redo

It turns out that Rake will only "invoke" a task once.... which works out great for tasks like "environment", which are given as a prerequisite to a lot of tasks and only actually NEED to be invoked once, but as this ticket proves, there are times when you just want to simply execute a task unconditionally without consideration as to whether it's been run already or not.

I wish Rake provided a standard method to unconditionally invoke a task. But since it doesn't, I wrote my own invoke_again method. It's not pretty but it works. (See attached patch.)

...
** Execute db:migrate
** Invoke db:schema:dump (first_time)
** Invoke environment
** Execute db:schema:dump
** Execute db:migrate:redo

Thanks Tyler-

Your patch works great, and saved me some Advil.