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
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
> 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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 2 Jun 2008, at 15:59, Moises Machado wrote:> > 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> 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 > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Frederick Cheung 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 > > FredThanks 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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---