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
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.