#107 Migrations in Rails 2.1

I was aware of the changes going up and down with the version but not of this. Nice screencast, as always :)

Keep it up

What if I want to rollback some migrations?Let's say I have

create_users
create_products
create_categories

and I want to roll back until the product migration.Before this changeset,I could easily do this by typing rake db:migrate VERSION=X

Where version number? I kid, the grammar nazi attacks. I think that is "their version number"

if i update rails to 2.1 and then run migrations on an existing project in 2.0 does this mean that i would have to rename all my db/migrate files? and since my migrations have already been run in my 2.0 project, the schema_migrations (which don't exist yet) also don't have the proper entries for tables that already exist... is there a rake task that will ready an existing rails 2.0 project to co-exist with 2.1 migrations?

@Alex, you can still do that, you'll just have to use the full timestamp as the specified version. What I usually do is run "rake db:rollback" as many times as needed.

@Don, thanks, fixed. :)

@sthapit, while I haven't fully tested this, I believe everything will just work. You don't have to rename anything, it will just use the existing version numbers. Also when you first run the migration I'm assuming it will properly generate the schema_migrations table and fill it will the existing entries. Someone please correct me if I'm wrong.

In Rails 2.1 you can now do migrations much more easier by the rake-tasks db:migrate:up, db:migrate:down, ...

this enables you to specify the version-number (now the timestamp) to migrate a single migration up and down :)

so if you want to delete migration number 15 out of 30 you don't have to rollback all the way or write a new one (31) which revert number 15.

example:
rake db:migrate:up VERSION=20080402122523

found in:

http://ryandaigle.com/articles/2008/4/2/what-s-new-in-edge-rails-utc-based-migration-versioning

lg

@QuBit thanks for bringing this up! I was originally planning on mentioning it in this episode, but I couldn't think of a good scenario on when I'd want to do this.

If I need to remove an older migration, I much prefer creating a new migration which does this, that way it applies on deployment and for any other developers who may have the code.

Does anyone know the reasoning behind the db:migrate:up/down additions?

I'm not sure what the original reason was for this, but it's made my life a lot easier when dealing with big datasets. For example I have an app with a cache of geographic information with 100K records which is a pain to constantly restore. While I'm still in development I frequently make changes to earlier migrations and just re-run them on my local, leaving the big dataset intact, without cluttering up the app with pre-production migrations.

I used to do this by going to the console and instantiating the class directly, but that was a pain.

So erm..... how do you actually create a timestamped migrations file? I always did File > New and gave it a name myself.

So erm... $ script/generate migration update_users of course.

nice screen cast alwasy. :)

Thanks for this update. I would like to point out an issue that arises when you freeze the current date for "today" in your application.

In general, the new version setting is fine because I doubt anyone was previously up to version 20080605122345. This is NOT ok if you're setting the time and date of "right now" in the application. For example, the date of present time is set to midnight, May 15th, 2007 in an app i'm working on (obviously development only). This means my new migrations (ALL of them) are given the same version of 20070515000000_.... and this is bad news.
I just manually rename them and all is well. An untrained developer picking up someone else's project might not notice this right away.

I see no benefits from the new naming convention.
How can I migrate to VERSION?

The way it was:

rake db:migrate VERSION=1

The way it is?

1) with either plain or timestamped version numbers, the migrations just care about the order of the numbers..
   It seems to be just a difference in how the number is generated.

2) you can disable timestamped migrations by putting this in your environment.rb file:

config.active_record.timestamped_migrations = false

3) If you have a project with a lot of developers who do schema changes, the timestamps will help.
   (Meetings will help more! ;-) )

   On the other hand you might have a project where you have a larger schema & dependency change,
   and you might need to renumber all your migrations to allow a smooth "rake migrate" (up and down).

   In this case you'd have to either "make up" fake timestamps for your migrations, or better: go back
   to plain version numbers for the migrations.
   

@Ryan Bates

I think you can use it to limit the number of migrations. So, if you need to change something in an existing migration, just edit it, migrate:down VERSION=xxx, migrate:up VERSION=xxx.

I like this because it keeps me from having a bunch of tiny migrations with column renames.

A little like gist vs pastie.

An example of a rake db:migrate:up would be if you are moving from one db to another (ie sqlserver version XYZ.1 to sqlserver version XYZ.2) and have a bunch of imported data (static data) as a migration.

So: rake db:schema:dump on sqlserverXYZ.1, goto sqlserverXYZ.2, do a rake db:schema:load

Then you would rake db:migrate:up VERSION=XXXXXXXXX (your import migrations).

That way - you don't have to worry about sqlserver version dependencies with migrations that may fail due to version incompatablity - but can still use the migration scripts needed to load your static data

Is there a simple way to move up or down by a single migration? I need to go through about 50 migrations, in order, examining the db after each (and looking at the migration output/errors.)

Moving along by typing out each version number is a pain. It would be great if I could do something like:

rake db:migrate VERSION=NEXT

Thanks...

Ryan - I hope you can help me with this. We had a mess with our production database. We just upgraded from Rails 1.2 to 2.3.2, so we had a schema_info table, no schema_migrations table. When we ran command for migrations, instead of it recognizing via the old schema_info table that we were at migration 64, it just started running all the migrations starting with 1. I don't know why the automatic table replacement didn't occur, but now I need to figure out how to clean it up. Should I just delete the schema_info table and manually create/populate a schema_migrations table?

as per comment #14 that says:

you can disable timestamped migrations by putting this in your environment.rb file:

config.active_record.timestamped_migrations = false

------

I tried this, but it still uses the timestamp version. Any ideas why?

How can we migrate comment text along with individual columns.

For column "status"
Comments are :
0- inactive
1- active
2 - hold

Need this data to fall when run rake db:migrate .