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
