On: How key-based cache expiration works

[dhh]

See step 6. The view is pulling the cache key straight from the domain model. It relies on being the informed as well about changes in its children to do that, which is what the setup in step 5 is about.

[Loic → dhh]

Do am I wrong or you still hit the DB for each model object? But of course you save all the complex rendering (possibly SELECT for children) from the key, right?

[dhh → Loic]

You hit the DB for the top-level. So in step 6, we'll always hit the db for the latest project, but we will not hit the db for the todolists or the todos of those todolists if the project cache is fresh.

So you save the render plus any db calls that would be triggered as part of that render.

[hasenj → dhh]

So simple yet so brilliant!

I can't believe I didn't think of this before. My initial reaction after I skimmed the post was "uhh, so you still hit the db? what's the point?"

Thanks for sharing this! I definitely want to implement something similar for my future projects!

[ludwigvan → Loic]

Not necessarily I believe, that one can be cached and invalidated manually.