cach invalidation help

I have the below code:

class ContactsController < ApplicationController

def top_3

cache_identifiers = { contact_1: 1, contact_2: 2, contact_3: 3 }

cache_keys = cache_identifiers.keys

cached_keys_with_values = Rails.cache.read_multi(*cache_keys)

uncached_keys = cache_keys.map { |key| key unless cached_keys_with_values.has_key?(key) }.compact

uncached_ids = uncached_keys.map { |key| cache_identifiers[key] }

uncached_contacts = Contact.where(id: uncached_ids).to_a

uncached_keys.zip(uncached_contacts).each do |key, value|

Rails.cache.write(key, value)

end

@contacts = cache_keys.map do |key|

cached_keys_with_values[key] || uncached_contacts.shift

end

end

end

I am using memcached as cache store. Now my question is how can I invalidate the cache when say any of the attributes(name, email) of the contact record changes.

Not sure were you got all of this code from… were you following an example somewhere?

This appears to be way overcomplicated for your use case.

The definitive and nearly ubiqutious method for simple object caching (incidentally, the singular form is spelled “cache,” as in a small hiding place. The word comes from the French, not to be confused with cachet, which also comes from French, and means “superior status” or “prestige”) is from the DHH post from 2013…

https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works

Assuming your objects are ActiveResource objects, you automatically get cache_key defined for you.

All you need to do is wrap the expensive (processing/time-intensive) code in the caching mechanism

Rails.cache.fetch(@contact)

// serialize or render the response data

end

… that’s it. As explained in DHH’s post from 2013, cache_key on @contact automatically includes the timestamp of when the record was last updated. When you make a change to any field the update_at timestamp changes, and so does the cache key, invalidating all caches associated with that cache key.

All of the other code you have looks like you went down a caching rabbit hole that is unnecessary. (But learning the internals of the Rails caching mechanism is a good thing for your own edification!)

-Jason

Correction: this referenced blog post is from 2012, not 2013