Model references fail in the initializer

rubyonrails-talk
1

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

2

Hi,

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

Do 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.

3

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

4

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.