Is it possible to run just one migration

I have modified an existing migration and I like to update the db with
that. But the problem is I'll to run all the migrations in order for
this change to take affect. That means I'll also loose all my data.

Is it possible to run just one migration? I know this is a weird case.
But I am interested in knowing if anybody has come across such a
situation and solved it.

This is what migrations are about. You don't modify existing ones, you
create new ones. Whatever you are doing to your schema, do it
incrementally in a new migration and run that. If it involves modifying
data to perform the migration, put that in the migration as well.

Migrations are not just about creating database tables. Any schema change
is a migration. Any migration (except those involving unrecoverable data
loss, which are very rare) should be reversible.

--Greg

Migrations are not just about creating database tables. Any schema change
is a migration. Any migration (except those involving unrecoverable data
loss, which are very rare) should be reversible.

Where do I insert dummy-data in my develop-database? In "Rails Cookbook" you can see often migrations, which create a table and insert same test-data.
But if you add an mandatory column to this table the insert will fail because the mandatory field only exists in the model and not in the migrations-file.

Martin

> Migrations are not just about creating database tables. Any schema
> change is a migration. Any migration (except those involving
> unrecoverable data loss, which are very rare) should be reversible.

Where do I insert dummy-data in my develop-database? In "Rails Cookbook"
you can see often migrations, which create a table and insert same
test-data.

Test data does not belong in migrations. That's what fixtures are for. I
don't have the Rails Cookbook, so I can't speak directly to what you've
found in it, but I'm surprised that it would recommend using migrations to
load test data, or even show it as an example.

But if you add an mandatory column to this table the insert will fail
because the mandatory field only exists in the model and not in the
migrations-file.

Keep your test data up to date with your schema, but not in your
migrations.

Martin

--Greg

Test data does not belong in migrations. That's what fixtures are for. I
don't have the Rails Cookbook, so I can't speak directly to what you've
found in it, but I'm surprised that it would recommend using migrations to
load test data, or even show it as an example.

No, I don't mean test-data for unit tests.

e.g.: two tables
users and types

class User < ActiveRecord::Base
   belongs_to :type
end

class Type < ActiveRecord::Base
   has_many :users
end

So I'd like to fill table types with 4 or 5 values so I can add users and develop the stylesheets etc for the users_controller.

The recommended approach for test data is using fixtures. I'm sure you
can find info on fixtures in the Rails Cookbook.

I've run a single migration this way:

$ ruby script/console

require 'db/migration/666_my_migration'
MyMigration.down

Or MyMigration.up, whatever suits you. I've done this, of course, only
when messing with migrations locally, before commiting them to the
repository. You should never change a migration that has gone to
production. And depending on what you're doing, you might need to
adjust the schema_version table manually. Hope that helps.

Cheers,

Helder

Its just the development database that I want to modify. I have the
habit of keeping everything to do with one table in a single migration
file. I find this better organized than scattering db modifications
across files. I know this can't be achieved once the migration is
deployed. But at least till I am in the development mode I try to do
that.

Using console to load the migrations is a good idea. Worked for me.
Thanks for the suggestion. I also tried:
./script/runner "require 'db/migrate/011_create_photos';
CreatePhotos.down"
./script/runner "require 'db/migrate/011_create_photos';
CreatePhotos.up"

..even that works.

-subbu