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
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/-/ibpv9J6pQocJ.
For more options, visit https://groups.google.com/groups/opt_out.
