Immutable migrations and regular ruby code

Guys,

I was working on a rails project and run into a nasty problem, I was
writing a migration that saved a model's data in another model and then
destroys it's table
the up code looks like

<code>
AnotherModel.find(:all) do |an_model|
  an_model.data = an_model.a_model.data #an_model has_one :a_model
end

drop_table :a_models
</code>

I run the migration and all wents fine but when I commited my changes to
the repository and my teammates checked it out it didn't run becouse the
AnotherModel no longer had the has_one relationship and the AModel class
don't even existed anymore.

So I refactored it to

<code>
AnotherModel.find(:all) do |am|
  a_model = ActiveRecord::Base.connection.select_one("select * from
a_models where another_model_id = #{am.id}")
  am.data = a_model["data"]
end

drop_table :a_models
</code>

so instead of using a nice clean code I had to use nasty SQL to do the
job

Then I realized that I just postponed the problem (can become a disaster
once we release) becouse the AnotherModel class can disapear in the
future (or be renamed) and we will have the same problem again.

So I wonder if using class models in the migration is really a good
thing becouse the version of the migrations is orthogonal to the version
in the repository so we have to guarantee that the migrations run in all
future versions, but accessing model class in the migration we tie it to
the current version and have to update the migration as we upgrade the
application.

But this violates the principle that migrations should be immutable and
that any change to the database schema should be made into a new
migration, so I have a dillema and here my options:

A) use the class models anyway and change the migration as the
application evolves and deal with the possible complications with
changed models and relationships

B) abolish all uses of class models in the migrations and use crude SQL

so what do you all think? There is other options? I'm sticking to A
becouse I have lots of model class code in migrations an little
background on SQL and connection adapters of rails. So please, help me!

MoisesMachado - thanks to listen

I'm sticking to A
becouse I have lots of model class code in migrations an little
background on SQL and connection adapters of rails. So please, help me!

Tempting to stick with Rails here.
But in cases like that I would go for SQL, since as you mentioned, you
can't be sure if a given model will still be available in future

Easy trick:

- Write the thing in RoR
- check your development.log
- copy the generated SQL

Guys,

So I wonder if using class models in the migration is really a good
thing becouse the version of the migrations is orthogonal to the
version
in the repository so we have to guarantee that the migrations run in
all
future versions, but accessing model class in the migration we tie
it to
the current version and have to update the migration as we upgrade the
application.

But this violates the principle that migrations should be immutable
and
that any change to the database schema should be made into a new
migration, so I have a dillema and here my options:

A) use the class models anyway and change the migration as the
application evolves and deal with the possible complications with
changed models and relationships

B) abolish all uses of class models in the migrations and use crude
SQL

Reproduce what you need of the class in the migration

class SomeMigration < ActiveRecord::Migration
   class Person < ActiveRecord::Base; end

   ...
end

I would never have anything apart from an empty class definition here
though (maybe the odd relationship), i.e. just use activerecord:base
to avoid some error-prone sql

Fred