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