[Rails] Re: Opinion on a particular use of Initializers

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.

Em quarta-feira, 21 de novembro de 2012 20h41min25s UTC-2, Frederick Cheung escreveu:

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 

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/Zup5h2klZPQJ.
For more options, visit https://groups.google.com/groups/opt_out.