Expiring Fragment caching

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

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

  1. The “Left Nav” menu for the current user (changes infrequently for a
  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

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?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs