I know that we shouldn''t make database calls in the Initializer, but how do we avoid this when a class ''bootstraps'' itself when it is required, e.g. class Status < ActiveRecord::Base # Add constants representing the various status SUBMITTED = self.find(...) APPROVED = self.find(...) DENIED = self.find(...) end I have, in my initialization block, a line which causes some model classes to be ''required'', e.g. config.active_record.observers = :audit_observer # ''requires'' observed classes My problem is that the initialization block runs while executing migrations, and therefore fails on a migration from version 0, because the Status table doesn''t yet exist. I''ve tried config.after_initialize, with no luck. Is there some other way to do initialization only after the migrations have run? Thanks. Brian -- 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 -~----------~----~----~----~------~----~------~--~---
Hi, On Fri, Oct 10, 2008 at 1:03 PM, Brian Hartin <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I know that we shouldn''t make database calls in the Initializer, but how > do we avoid this when a class ''bootstraps'' itself when it is required, > e.g. > > class Status < ActiveRecord::Base > # Add constants representing the various status > SUBMITTED = self.find(...) > APPROVED = self.find(...) > DENIED = self.find(...) > endDo these need to be constants? How about: class Status < ActiveRecord::Base class << self def submitted @submitted ||= find(...) end end end Or, if they''re simple enough, they could just be named scopes: class Status < ActiveRecord::Base named_scope :submitted, :conditions => [...] end ~ j. --~--~---------~--~----~------------~-------~--~----~ 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 had thought about making them class methods; that would work. It just seemed more proper for them to be constants. I have at least one more place where I''m doing ''class-load'' time DB access. I''ll have to see if I can make it ''lazily evaluated''. Since the prevailing thought is that a Rails app isn''t fully initialized until the migrations have run (thus the caution against using models in migrations), I wonder if it would be possible to programatically distinguish between a Rails env in which migrations had been fully run and otherwise. Thanks for the response. Brian -- 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 Oct 11, 4:29 am, Brian Hartin <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I had thought about making them class methods; that would work. It just > seemed more proper for them to be constants. > > I have at least one more place where I''m doing ''class-load'' time DB > access. I''ll have to see if I can make it ''lazily evaluated''. > > Since the prevailing thought is that a Rails app isn''t fully initialized > until the migrations have run (thus the caution against using models in > migrations), I wonder if it would be possible to programatically > distinguish between a Rails env in which migrations had been fully run > and otherwise. >initialization in the sense of initializers and config.after_initialize corresponds purely to ''have all the framework files, plugins etc...'' been setup and initialized. It does not have anything to do with migrations. In that sense the framework is fully initialized before migrations are run. You might be able to play around with the stuff in ActiveRecord::Migrations to figure out that sort of stuff, although it feels like a better way is to just make it not an issue. Fred --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
If the only time you''re worried about your code failing is during the migration you can simply add a check to see if the table exists and if not don''t execute the code. it''s not a very clever solution but does the job. On Oct 10, 4:03 pm, Brian Hartin <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I know that we shouldn''t make database calls in the Initializer, but how > do we avoid this when a class ''bootstraps'' itself when it is required, > e.g. > > class Status < ActiveRecord::Base > # Add constants representing the various status > SUBMITTED = self.find(...) > APPROVED = self.find(...) > DENIED = self.find(...) > end > > I have, in my initialization block, a line which causes some model > classes to be ''required'', e.g. > > config.active_record.observers = :audit_observer # ''requires'' observed > classes > > My problem is that the initialization block runs while executing > migrations, and therefore fails on a migration from version 0, because > the Status table doesn''t yet exist. > > I''ve tried config.after_initialize, with no luck. Is there some other > way to do initialization only after the migrations have run? > > Thanks. > > Brian > -- > Posted viahttp://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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---