rake db:redo & rake migrations:reset - or how to cope with the change of db:reset

As many of you know, rake db:reset changed behavior just before Rails 2.0 got released.

db:reset used to drop the database, re create it and migrate it up. The core team after integrating this feature, realized that it was not used as intended and instead db:create now uses the schema.rb file instead of the migrations.

Check the many discussions we had about this topic, you will quickly notice that the Core team made a decision which is consistent with their beliefs however they did admit there is a need to offer an alternative solution, especially in the testing and development environment.

In order to provide with my personal needs, I decided not to overwrite rake db:reset (even though I'm the author of the original patch). Instead I agreed with David that in production mode db:reset should use the schema.rb file.

I could have split the db:reset task to behave differently depending on the environment, but I think that would be way too confusing. Instead I came up with another approach.

First, rake db:redo http://dev.rubyonrails.org/ticket/10431 which takes care of 85% of my development issues after the db:reset switch.

rake db:redo 'resets/re-does' the last migration. Technically, it migrates down one (or more steps) and then migrate up. This task works perfectly.... well almost. Migrating down sometimes breaks(you might have added a new column that can't be removed since it didn't exist until now).

That's where my other task becomes handy:

rake migrations:reset http://dev.rubyonrails.org/ticket/10432 Basically this task behaves the same as the old rake db:reset task. However as explained in other posts, this task should only be used to test the migrations or when you are stuck and can't use rake db:redo that's why it was moved outside of the db namespace.

This is quite a simple solution and it certainly doesn't address the need for a seeder, but I sincerely believe it would cover most of the use cases while staying consistent.

-Matt

Hey Matt,

I feel your pain on this one, and must say that I definitely noticed the change when db:reset started loading schema.rb. I really started to appreciate using db:reset a lot when building out new models.

Your proposed functionality for "db:redo" would certainly come in handy, but it doesn't quite feel right to have a task dedicated just to rolling back N migrations and back up to the current. The functionality of your proposed "migrations:reset" sounds about right, but the name is a bit unwieldy.

Currently I have a shell alias "remigrate" for "rake db:drop db:migrate db:test:prepare" -- maybe "rake db:remigrate" would be a better name for your "rake db:migrations:reset"?

Thanks Nick for your reply. Quick note about:

"Currently I have a shell alias "remigrate" for "rake db:drop db:migrate db:test:prepare" -- maybe "rake db:remigrate" would be a better name for your "rake db:migrations:reset"? "

the rake task would be rake migrations:reset not rake db:migrations:reset

I'm fine with calling it anything really :stuck_out_tongue:

-Matt