Forum: Ruby on Rails Model references fail in the initializer

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
218ad981316abb835a853bdf6d3039af?d=identicon&s=25 Brian Hartin (bjhartin)
on 2008-10-10 22:03
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
C237cf537a06b60921c97804679e3b15?d=identicon&s=25 John Barnette (Guest)
on 2008-10-11 00:18
(Received via mailing list)
Hi,

On Fri, Oct 10, 2008 at 1:03 PM, Brian Hartin
<rails-mailing-list@andreas-s.net> 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.
218ad981316abb835a853bdf6d3039af?d=identicon&s=25 Brian Hartin (bjhartin)
on 2008-10-11 05:29
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
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2008-10-11 12:24
(Received via mailing list)
On Oct 11, 4:29 am, Brian Hartin <rails-mailing-l...@andreas-s.net>
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
613c0cc9552a2c880a902bb109c885b0?d=identicon&s=25 Youssef Chaker (Guest)
on 2008-10-11 14:04
(Received via mailing list)
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...@andreas-s.net>
This topic is locked and can not be replied to.