[pilif]

True, if it's possible.

Let's say that hugetable is some interface table filled by a different system you have no control on. You could add a trigger on the database that shells out to some script to clean the cache, but if the that external tool adds rows one by one, that's really expensive (aside of the fact that this is NOT what triggers were invented for).

Or the data in hugetable depends on a lot of different components in your application. Then it's really hard to always be sure to invalidate the cache correctly and there's sure to be a location where you'll forget.

In addition, invalidating the cache on write works counter to the pattern described in the tutorial that concentrates the caching around retrieval.

Don't get me wrong: I agree with the article. It's just never as easy as these tutorials make it seem.

[mattlanger]

In what way was this a tutorial? Seemed more like a parable meant to drive home the line about how "When they have questions, they ask the mailing list or read the faq again."

Each problem poses different challenges, and it doesn't seem fair to attempt to invalidate a given example by theorizing about hypothetical complexities the original authors never alluded to.

[pilif]

You misunderstood the intent of my possible continuation of the original post. I was not trying to invalidate it, but just noting what problems might (and do) arise.

I totally agree with all the article says. Caching in general and especially memcache are awesome, but as always it's a trade off. What you get in performance, you pay for in complexity