# Expiring Fragment caching

**URL:** <https://www.ruby-forum.com/t/expiring-fragment-caching/137402>\
**Category:** Rails\
**Created:** [May 12, 2008, 9:44pm UTC](https://www.ruby-forum.com/t/expiring-fragment-caching/137402 "2008-05-12T21:44:30Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![railsdog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b77776/32.png) [@railsdog](https://www.ruby-forum.com/u/railsdog)\
**Post date:** [May 12, 2008, 9:44pm UTC](https://www.ruby-forum.com/t/expiring-fragment-caching/137402/1 "2008-05-12T21:44:30Z")

</div>

The standard Cache sweepers seem to work on too big a scale for what I’d  
like…

I’m caching and reading three different fragments on a page:

1. The “Left Nav” menu for the current user (changes infrequently for a  
user).
2. The main content area, which caches the ‘show’ action for the current  
model instance, and expires after update or destroy for a model.
3. A context menu for the current model instance, which shows links to  
things related to the current model (links to various parent and child  
models which uses the name and a short description of each related  
model).

The quirk is that I’d like to not be so “heavy handed” with  
“after\_update” when expiring these context menu fragments…

For some reference, I have:  
a Project model, has\_many :scenarios  
a Scenario model, belongs\_to :project, has\_many :tests  
a Test model, belongs\_to :scenario, has\_many :docs

If I:

1. add a new Scenario to a Project, the project’s context cache should  
be expired (it has a new scenario to show)
2. change the name or description of a scenario, the project’s context  
menu cache should be expired, and the scenario’s tests’ context caches  
also (the scenario’s name and description are in those caches)
3. change anything else, and the project’s context menu is fine as it  
is, as are all the tests’ context menu caches

Now, on any given editing form, there are a host of fields I can change  
that don’t have to cause the context menu cache of related models to be  
expired… Internal Notes, Start Date, End Date, etc, etc, but there  
are two fields that should cause the expiration (name and description).

When updating the scenario, the standard Sweeper’s after\_update can’t  
catch this distinction, so I’m leaning towards having the scenario model  
do some expiring, and leaving the standard cache sweeper just managing  
the after\_destroy work… at which point, I’m wondering why I need the  
sweeper at all?

Opinions? Anyone doing something different?