Will rake db:migrate:down VERSION=XXX completely remove that migration from Rails?

What exactly does rake db:migrate:down VERSION=XXX do? I understand
that it runs the “down” migration, completely removing any columns/
tables that migration may have created, but does this mean that I can
can delete these migration files as well? I’d like for Rails to have
no knowledge of their existence. (I was allowing user profile pics
with Paperclip, but have since decided to just use their Gravatars.)

I know you can delete a migration, and even delete those columns from
the schema, but Rails still “remembers” these changes and just updates
them the next time you rake db:migrate. So, I’d like to completely
rid my app of a particular migration, is rake db:migrate:down then
deleting that migration from the migrate folder the way to do it?

You’ll also need to remove that migration’s entry from the
‘schema_migrations’ table. That’s how Rails keeps up with what
migrations exist, and whether it’s done them all.

Thanks Ryan

and, I hope this isn’t too stupid of a question, but where is this
‘schema_migrations’ table?

It is in whatever database your app is using. Rails creates and
maintains it for you. So if your production database is ‘foo_prod’,
there would be a ‘schema_migrations’ table there, as well as in your
‘foo_dev’ development database.

I don’t know of a simple way to remove that row without firing up your
database itself (MySQL or whatever).

So as long as I rake db:migrate:down and delete the migration file
from my local machine, the production database on the server when it
does go live (I haven’t launched the app yet) will have no knowledge
of this migration having ever existed, right?

because that’s all I really care about, and I believe this is true, at
least from from my understanding now

Thank you again Ryan

On Tue, Apr 6, 2010 at 11:29 PM, Ryan W. [email protected] wrote:

You’ll also need to remove that migration’s entry from the
‘schema_migrations’ table. That’s how Rails keeps up with what
migrations exist, and whether it’s done them all.

Running rake db:migrate:down VERSION=XXX should remove the entry.

Otherwise rake db:migrate wouldn’t run the migration again. A normal
use case for migrate down is:

rake db:migrate

#oops something was wrong in migration 123456
rake db:migrate:down VERSION=123456
edit db/migrate/123456_whatever_it_does
rake db:migrate

On Tue, Apr 6, 2010 at 10:10 PM, GoodGets [email protected] wrote:

What exactly does rake db:migrate:down VERSION=XXX do? I understand
that it runs the “down” migration, completely removing any columns/
tables that migration may have created,

Well it does whatever YOU told it to in the down part of the
migration. It’s up to you (or whatever you use to edit/generate the
migration) to write the correct code there.

I tend to use Textmate snippets from the rails bundle to do
migrations, and the table/column migration snippets will generate
‘undo’ code in the down migration when you expand them in the up
migration. But YMMV depending on what tools you use.

but does this mean that I can
can delete these migration files as well? I’d like for Rails to have
no knowledge of their existence. (I was allowing user profile pics
with Paperclip, but have since decided to just use their Gravatars.)

I know you can delete a migration, and even delete those columns from
the schema, but Rails still “remembers” these changes and just updates
them the next time you rake db:migrate. So, I’d like to completely
rid my app of a particular migration, is rake db:migrate:down then
deleting that migration from the migrate folder the way to do it?

When you do rake db:migration the rake task looks for migrations
under db/migrate which don’t have entries in the schema_migrations
table, and runs those (actually I think it’s a bit more subtle than
that, there’s been discussion of a ‘bug’ which can make the task
ignore migrations with a timestamp older than the newest one in
schema_migrations, which can keep migrations merged from another
branch NOT to be run. But…

If you run

rake db:migrate:down version=XXX

and then remove the file db/migrate/XXX_whatever from your source, the
rake task won’t see it and it will be gone.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

On Wed, Apr 7, 2010 at 1:10 PM, GoodGets [email protected] wrote:

So as long as I rake db:migrate:down and delete the migration file
from my local machine, the production database on the server when it
does go live (I haven’t launched the app yet) will have no knowledge
of this migration having ever existed, right?

because that’s all I really care about, and I believe this is true, at
least from from my understanding now

Thank you again Ryan

HA! My only contribution here was to miss the explanation badly
enough to motivate Rick to write a longer and actually correct one. :slight_smile:

Wow.
Thank you Rick. Very nice explanation.
Yeah, I dropped the columns by raking ‘down’ and have also deleted
that migration, so I think I’m good to go now. Also, I don’t use
textmate, but yeah, I made sure that the “down” migration removed all
the columns the “up” created.

Thank you again Mr. Rick