Open levonmaa opened 6 years ago
You can manually clear the cache with Rails.cache.clear, or use the expires_in param of fetch to force the cache to invalidate after a few hours or days. Cachehelpers will normally only invalidate the cache if the object you’re caching with (assignment) has been modified in a way that touches the updated_at field, unless you’re providing a static key. Since this is a structural change of the template though that would affect all assignments, I would just clear the cache of the server when you deploy the updated code.
I think @levonmaa has a valid concern/idea. We use jb extensively and going in and manually expiring cache can be rather nettlesome. It would be useful to expire the cache of the template when it changes.
Two late thoughts on that:
v1
is not being used within the template and maybe it shouldn't be used anywhere else. So use it as a version number and make sure to increase it anytime you change the structure of the template. If you can't: introduce another string element carrying a version number as part of the cache key. You're editing the template anyway...assignment
and (at least it looks like) there are no further heavy computations involved. Is it really worth employing the Rails cache (e.g. Redis calls) here? This even requires some kind of serialisation of assignment
to use it as a cache key, I assume. I haven't made a performance analysis, of course...
Curently I have a template that has the following
And it caches out nicely.
But when I edit the template contents, say add a new item there, the cache does not invalidate. I know that ActionView::Helpers::CacheHelpers has functionality for this, but how to take advantage of it?