views:

14

answers:

1

While reading up on caching options for Rails, I've just watched the Scaling Rails episode on memcached, where they advocate using the updated_at field of a record as part of the cache key. This is supposed to ensure that when a cache block contains the contents of a record, whenever that record gets updated, it will invalidate that cache block.

I understand the principle, but if I know the current updated_at time of a record, doesn't that imply I've recently hit the DB already? How does that help?

This would seem to suggest it's only useful in cases where you're making multiple accesses to the same record throughout a session or building a view, each with different queries, and only some of them are cache worthy. Is that the intent here?

A: 

We use this technique with belongs_to …, :touch => true.

This ensures that if any of the dependant items are tainted, the master is tainted too. We do this for Product -< Price type relationships. One simple primary key lookup determines if we need to load many other records (& do maths) or just use the cache.

It's no magic bullet, but it works, and the timestamps can be pushed all the way out to HTTP cache control headers saving whole requests.

cwninja