Question

I’m reading this article:

http://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works

I’m not using rails so I don’t really understand their example.

It says in #3:

When the key changes, you simply write the new content to this new
key. So if you update the todo, the key changes from
todos/5-20110218104500 to todos/5-20110218105545, and thus the new
content is written based on the updated object.

How does the view know to read from the new todos/5-20110218105545 instead of the old one?

Answer 1

I was confused about that too at first — how does this save a trip to the database if you have to read from the database anyway to see if the cache is valid? However, see Jesse’s comments (1, 2) from Feb 12th:

How do you know what the cache key is? You would have to fetch it from the database to know the mtime right? If you’re pulling the record from the database already, I would expect that to be the greatest hit, no?

Am I missing something?

and then

Please remove my brain-dead comment. I just realized why this doesn’t matter: the caching is cascaded, so yes a full depth regeneration incurs a DB hit. The next cache hit will incur one DB query for the top-level object—all the descendant objects are not queried because the cache for the parent object includes cached versions for the children (thus, no query necessary).

And Paul Leader’s comment 2 below that:

Bingo. That’s why is works soooo well. If you do it right it doesn’t just eliminate the need to generate the HTML but any need to hit the db. With this caching system in place, our data-vis app is almost instantaneous, it’s actually useable and the code is much nicer.

So given the models that DHH lists in step 5 of the article and the views he lists in step 6, and given that you’ve properly setup your relationships to touch the parent objects on update, and given that your partials access your child data as parent.children, or even child.children in nested partials, then this caching system should have a net gain because as long as the parent’s cache-key is still valid then the parent.children lookup will never happen and will also be pulled from cache, etc.

However, this method may be pointless if your partials reference lots of instance variables from the controller since those queries will already have been performed by the time Rails sees the calls to cache in the view templates. In that case you would probably be better off using other caching patterns.

Or at least this is my understanding of how it works. HTH