Re: Opinion on a particular use of Initializers

[Frederick Cheung]

On Wednesday, November 21, 2012 5:57:15 PM UTC, Alex Braha Stoll wrote:

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 

[Alex Braha Stoll]

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.

[Jordon Bedwell]

On Wed, Nov 21, 2012 at 8:57 PM, Alex Braha Stoll
<alexbra...@gmail.com> wrote:
> 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?

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.

[Frederick Cheung]

On Thursday, November 22, 2012 2:57:46 AM UTC, Alex Braha Stoll wrote:

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

[Alex Braha Stoll]

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.