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 [email protected]. To unsubscribe from this group, send email to [email protected]. 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.
