Immutable migrations and regular ruby code

rubyonrails-talk
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

<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

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

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