> What are some general strategies for handling caching in a situation
> like this?

Fragment caching sounds like the way to go.

For index views, I cache my "standard" data on a per row basis, but not 
the edit/destroy links, as those depend on the user viewing the data and 
their rights/permissions.  The caching still helps with performance 
since the "standard" data includes columns assembled from other models 
in the database, and I don't use eager loading.

Naming your fragments specifically makes the cache management easier in 
a complicated case (I use a modeltype.id.cachetype naming scheme like 
project.1.show, project.1.relateds, project.1.related.scenarios, etc).

I wouldn't bother caching the banner.
You could cache all but the voting link on the index view (just make 
that the first or last item on the row for simplicity).
I wouldn't cache your sidebar, as it would change frequently (unless it 
can be broken into chunks like profile, recent this, recent that).

My sidebar in a 'show' method shows all the models related to the 
current model grouped by model type (a project can have related 
scenarios, images, applications, modules, and areas). I cache the whole 
'related' sidebar, as well as the sidebar components -- related models 
of type X.  When a new scenario gets related to a project, for example, 
that expires the project's 'related scenarios' fragment, and the overall 
'related models' fragment. Next time the project is viewed, the missing 
'related models' fragment means that it has to check each related model 
fragment. In this case only the related scenarios would have to be 
re-read and a new cache fragment generated -- the other 4 fragments are 
still valid.

All that kind of work and logic is coded in a GenericModel class that 
sits between ActiveRecord::Base and my real models like Project, 
Scenario, etc, so it's easy to have new models adopt the caching 
mechanism.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to