# Model references fail in the initializer

**URL:** <https://www.ruby-forum.com/t/model-references-fail-in-the-initializer/150655>\
**Category:** Rails\
**Created:** [October 10, 2008, 10:03pm UTC](https://www.ruby-forum.com/t/model-references-fail-in-the-initializer/150655 "2008-10-10T22:03:10Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![kuma](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a587f6/32.png) [@kuma](https://www.ruby-forum.com/u/kuma)\
**Post date:** [October 10, 2008, 10:03pm UTC](https://www.ruby-forum.com/t/model-references-fail-in-the-initializer/150655/1 "2008-10-10T22:03:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kuma](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a587f6/32.png) [@kuma](https://www.ruby-forum.com/u/kuma)\
**Post date:** [October 11, 2008, 12:18am UTC](https://www.ruby-forum.com/t/model-references-fail-in-the-initializer/150655/2 "2008-10-11T00:18:44Z")

</div>

Hi,

On Fri, Oct 10, 2008 at 1:03 PM, Brian H.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

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.

---

<div class="post-metadata">

**Author:** ![kuma](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a587f6/32.png) [@kuma](https://www.ruby-forum.com/u/kuma)\
**Post date:** [October 11, 2008, 5:29am UTC](https://www.ruby-forum.com/t/model-references-fail-in-the-initializer/150655/3 "2008-10-11T05:29:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kuma](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a587f6/32.png) [@kuma](https://www.ruby-forum.com/u/kuma)\
**Post date:** [October 11, 2008, 12:24pm UTC](https://www.ruby-forum.com/t/model-references-fail-in-the-initializer/150655/4 "2008-10-11T12:24:06Z")

</div>

On Oct 11, 4:29 am, Brian H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> 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

---

<div class="post-metadata">

**Author:** ![kuma](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a587f6/32.png) [@kuma](https://www.ruby-forum.com/u/kuma)\
**Post date:** [October 11, 2008, 2:04pm UTC](https://www.ruby-forum.com/t/model-references-fail-in-the-initializer/150655/5 "2008-10-11T14:04:16Z")

</div>

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 H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)