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

[Matt Aimonetti]

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

[Nick Zadrozny]

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"?

--
Nick Zadrozny * http://nick.zadrozny.com/

[Matt Aimonetti]

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 :p

-Matt