Immutable migrations and regular ruby code

Rails
1

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

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

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

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

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

2

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
3

On 2 Jun 2008, at 15:59, Moises Machado wrote:

the current version and have to update the migration as we upgrade the

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

4

Frederick C. wrote:

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

Thanks man I think I will use this.

It seems to make a lot more sense because it captures the state things
were with code that I really writed, not a fancy sql that seems came out
of nowhere the other idea is good too but it’s not as beautiful and I
would anyway write the original code that geneterated that sql in the
comments and I don’t like to use automated generated code mixed with
handwrited code (except code templates)

Thanks once more