I have some classes in my model which use STI and they work as expected in the console. However, when I try to use them in a migration, I get "uninitialized constant OfficePhone", for example. Why doesn''t the migration environment pick up the class defs? OfficePhone is defined in the model/phone.rb. I put model :phone in the application.rb but my migration just doesn''t seem to pick it up. Any ideas? Steven -- Posted via http://www.ruby-forum.com/.
On 6/10/06, Steven Talcott Smith <steve@talcottsystems.com> wrote:> I have some classes in my model which use STI and they work as expected > in the console. However, when I try to use them in a migration, I get > "uninitialized constant OfficePhone", for example. Why doesn''t the > migration environment pick up the class defs? OfficePhone is defined in > the model/phone.rb. I put model :phone in the application.rb but my > migration just doesn''t seem to pick it up. Any ideas? >You should put each subclass in its own file. Phone should be in phone.rb OfficePhone should be in office_phone.rb etc. That will let you get rid of the "model :phone" line, and also let you use them without difficulty in migrations.
Very true. What you''ll find is that you can use OfficePhone as long as you have already used Phone. Using Phone will cause phone.rb to be loaded, which inadvertently also loads the definition of OfficePhone. -Jonathan. On 6/11/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:> > You should put each subclass in its own file. > Phone should be in phone.rb > OfficePhone should be in office_phone.rb > etc. > > That will let you get rid of the "model :phone" line, and also let you > use them without difficulty in migrations. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Steven Talcott Smith wrote:> I have some classes in my model which use STI and they work as expected > in the console. However, when I try to use them in a migration, I get > "uninitialized constant OfficePhone", for example. Why doesn''t the > migration environment pick up the class defs? OfficePhone is defined in > the model/phone.rb. I put model :phone in the application.rb but my > migration just doesn''t seem to pick it up. Any ideas? > > Steven >Along with what has already been mentioned: "Don''t use your ActiveRecord models in your migrations or your life will be miserable" http://rails.techno-weenie.net/tip/2006/2/23/safely_using_models_in_migrations -- R.Livsey http://livsey.org
Richard Livsey wrote:> Along with what has already been mentioned: > > "Don''t use your ActiveRecord models in your migrations or your life will > be miserable" > > http://rails.techno-weenie.net/tip/2006/2/23/safely_using_models_in_migrationsThanks, I appreciate this and I too discovered that if I use the parent class, I can get away with it. I am writing a one-time series of migrations of a production database to a new railsified schema so my model is evolving together with the migrations and it helps me a lot to go back and re-run the series of migrations constantly as I define the models. I certainly understand the long term problem of keeping migrations around that use obselete models but once I am in production, I will never need these migrations again and will probably restart the migration counter at 0. Thanks again for the tips! After cutover, I certainly will include any required model defs in my migrations. Steven -- Posted via http://www.ruby-forum.com/.