Opinion on a particular use of Initializers

Since the profile ids (and other ‘constants’ stored in the database) can only change if the sys admin changes their values before the deploy (editing seeds.rb), I though of using initializers to retrieve references to all those database constants (therefore opening less connections with the database during application usage):

I don’t think this will affect the number of connections to the database, although you will of course save some queries

I have tested this solution and it works perfectly fine. However, I would like to know from veteran Rails developers if this is a good (or acceptable) use of initializers (and if this should really increase performance).

Personally if this was worthwhile for my app I would load the profiles lazily rather than in an initializer. One reason is that initializers get run in a lot of cases where you probably don’t need those rows cached, eg rake routes.

Occasionally this sort of stuff can bite you too - depending on how you deploy the app, the profiles table might not exist (fresh deploy). So you run rake db:schema:load to set things up, but that would also load you initializer and would therefore blow up when that initializer tried to access the profiles table.

Fred

Thanks for the answer, Fred.

When you say lazily loading the data I need you mean waiting for a first request that uses the data, right? If so, how can I do that in a way that the data will persist for the next requests (from the same and from other users)? Just storing the data into a class that checks if the constants were already fetch doesn’t guarantee the persistence of the data between requests, right? Can you point me a resource where I can learn more about a solution for my scenario?

Cheers,

Alex.

Most objects should persist between requests so if you were to create
a struct and load all your data onto that struct the object would be
persisted between requests. You could just create a Persist object
with an initializer and and there is your persistent struct.

Thanks for the answer, Fred.

When you say lazily loading the data I need you mean waiting for a first request that uses the data, right? If so, how can I do that in a way that the data will persist for the next requests (from the same and from other users)? Just storing the data into a class that checks if the constants were already fetch doesn’t guarantee the persistence of the data between requests, right? Can you point me a resource where I can learn more about a solution for my scenario?

I mean something like

class Profile < AR::Base

def self.cached

@cached ||= begin

#build up the hash of profiles

end

end

end

Then do Profile.cached[:foo] when you need it

Fred

Thank you both Fred and Jordon for the help.

I followed Fred’s code example and ended with the following solution:

class Profile < ActiveRecord::Base

has_many :person_profiles

has_many :people, through: :person_profiles

def self.cached

@@profiles ||= fetch_data

end

def self.fetch_data

temp_profiles = {}



Profile.all.each do |profile|

  case profile.name

    

  when 'admin'

    temp_profiles[:admin] = profile



  when 'super-admin'

    temp_profiles[:super_admin] = profile

    

  # ... other profiles

  end       

end



temp_profiles

end

end

In the controller:

@admins = Profile.cached[:admin].people

Doing some tests, I noticed that starting on the second request there is a significative difference in ActiveRecord´s total processing time. However, if all the users log out, it seems that the garbage collector sweeps the data cached in the class variable. When I have time, I will further investigate this in order to find a way to persist that data for all the time the application is running.

Cheers,

Alex.