On Fri, Apr 10, 2009 at 9:25 AM, Shak Shak
<[email protected]> wrote:
>
> Andrew Timberlake wrote:
>> On Thu, Apr 9, 2009 at 5:40 PM, Shak Shak
>> <[email protected]> wrote:
>>> doesn't need to (in fact, shouldn't) last past a single request.
>>>
>>> An instance variable in ApplicationController sounds like it would do
>>> this, but I would say such data should be kept with the model. Of course
>>> a class variable in the model will keep its value each request (in
>>> production) so is inappropriate for this.
>>>
>>> Any ideas?
>>>
>>> Shak
>>> --
>>
>> It may be useful to understand a little more of what you're trying to
>> achieve.
>> If you're needing to keep something around for a request, an instance
>> variable in the controller may the right place because that manages
>> the the request.
>
> My application often needs a list of application-specific "types". This
> is a relatively static list of AR models. I also create sub lists based
> on attributes of those types - so all the ones whose names which begin
> with the letter "A", for instance. Each list is formed from a traversal
> of the full list. These sub lists are accessible via the Class -
> ApplicationTypes.get_all_a, for example.
>
> To not repeat these traversals, I cache the computed lists. At the
> moment, I'm using MemoryStore. Caching AR models there requires a
> Marshal due to some odd (but known) behaviour
> (https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1339).
> Taking stuff from the cache requires an unmarshall. Other cache stores
> implicitly Marshal anyway.
>
> So to save the repeated unmarshalling, I wanted a way to keep the
> results of unmarshalling things from the cache on a per-request basis.
> It's interesting to note that Rails 2.3 has this built in (for remote
> caches, anyway). From the release notes:
>
> "5.8 Improved Caching Performance
>
> Rails now keeps a per-request local cache of read from the remote cache
> stores, cutting down on unnecessary reads and leading to better site
> performance. While this work was originally limited to MemCacheStore, it
> is available to any remote store than implements the required methods."
>
> I just want this kind of behaviour for a memorystore backed cache.
>
> At the moment, I've just created a local hash of cached objects (created
> on retrieval), which I clear using a public function called from an
> before_filter in the ApplicationController. I guess this is the MVC way
> of doing it too (maybe?). I do wonder how the mechanism in Rails 2.3
> works though (since my way isn't really threadsafe), so any further
> ideas would be welcome.
>
> Shak
> --
Shak
If you're just keeping this information around for the request, I
don't know why you are storing it anywhere other than in the
controller as it is going to be re-calculated for every subsequent
request.
A simple example of this is authentication where a current user is
required throughout the request but will be a (potentially) different
user for each request processed by Rails.
This is a perfectly acceptable thing to store in the controller implement like:
class ApplicationController < ...
...
def current_user
@current_user ||= get_current_user_somehow
end
...
end
This way the user is 'figured out' once and then cached for each
subsequent call to current_user but finally discarded when the request
is complete.
Andrew Timberlake
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake
"I have never let my schooling interfere with my education" - Mark Twain
--~--~---------~--~----~------------~-------~--~----~
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]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
