# Immutable migrations and regular ruby code

**URL:** <https://www.ruby-forum.com/t/immutable-migrations-and-regular-ruby-code/139286>\
**Category:** Rails\
**Created:** [June 2, 2008, 4:59pm UTC](https://www.ruby-forum.com/t/immutable-migrations-and-regular-ruby-code/139286 "2008-06-02T16:59:36Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![moisesmachado](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/9de053/32.png) [@moisesmachado](https://www.ruby-forum.com/u/moisesmachado)\
**Post date:** [June 2, 2008, 4:59pm UTC](https://www.ruby-forum.com/t/immutable-migrations-and-regular-ruby-code/139286/1 "2008-06-02T16:59:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![moisesmachado](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/9de053/32.png) [@moisesmachado](https://www.ruby-forum.com/u/moisesmachado)\
**Post date:** [June 2, 2008, 5:05pm UTC](https://www.ruby-forum.com/t/immutable-migrations-and-regular-ruby-code/139286/2 "2008-06-02T17:05:16Z")

</div>

> 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

---

<div class="post-metadata">

**Author:** ![moisesmachado](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/9de053/32.png) [@moisesmachado](https://www.ruby-forum.com/u/moisesmachado)\
**Post date:** [June 2, 2008, 5:25pm UTC](https://www.ruby-forum.com/t/immutable-migrations-and-regular-ruby-code/139286/3 "2008-06-02T17:25:50Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![moisesmachado](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/9de053/32.png) [@moisesmachado](https://www.ruby-forum.com/u/moisesmachado)\
**Post date:** [June 2, 2008, 5:41pm UTC](https://www.ruby-forum.com/t/immutable-migrations-and-regular-ruby-code/139286/4 "2008-06-02T17:41:34Z")

</div>

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