Hacker News Reader

Comment by freedrull | Hacker News Reader

I use most of these methods for caching. I have my own little methods for making cache keys. I use Rails.cache all over the place. I have a couple sweepers. What I really struggle is testing this stuff. You really can't do it anywhere other than an integration test, and they're ugly. I mostly just test the sweepers. Anyone have any nice solutions for testing caching, or think its unnecessary?

View on HN

I would try to remove as much caching as possible. It is complicated and hard to test.

I've never had a production Rails project, but do you have any anecdotes or numbers to back up your statement? From initial glance, it looks like the win in processing speed outweights the complexity. So then you're implying that this win isn't required. I'm assuming that scaling out is cheaper than the complexity cost of implementing/maintaining such a caching solution?

I haven't had a lot of experience with caching, and I agree with your comment above about database views, but wouldn't the complications be mitigated by using the approach DHH detailed recently? http://37signals.com/svn/posts/3113-how-key-based-cache-expi...

That is, incorporating `updated_at` into the cache key, and using `touch: true` on your AR relations to make sure that caches of affected parent objects get expired too?

Are there other complications I may not have run into yet?

Imagine you have User has_many Comments. When someone's username is updated, you might need to update all the user's cached html comment fragments to include the new username.

However, ActiveRecord doesn't support touch on has_many relations. (It probably shouldn't, as updating the username would mean updating/touching thousands (or more) comment rows).

Also, if you have to update the database outside of ActiveRecord for any reason, you could be screwed - the cache would become out of sync with the database.

Cheers, a helpful and extremely likely case!

Reply on news.ycombinator.com