we have the case currently, that the hard coded call to cacheable.cache_key in the Plan is not outdating our
cache when we update a model. The reason is, that the Model#cache_key value does not change after the model is updated, which is correct behavior for Rails >= 5.2 since the cache_key method should be used to for "recyclable" cache keys.
Cache versioning is disabled by default for Rails 5.2, >= 6.0 (ActiveRecord::Base.cache_versioning = false).
Cache versioning is enabled by default for Rails >= 6.0 (ActiveRecord::Base.cache_versioning = true).
I opened this PR for a few reasons instead of just overwriting cache_key on my models:
I would have to overwrite it for every model or in the base model, which is probably a bad idea for existing applications, that use caching in other cases than serializing models (e.g. rendering views).
I would loose the recyclable cache_key that I'll probably need in another place.
I think it would be a good thing to be able to change the CacheCrispies default from cache_key to cache_key_with_version in a future major release.
I had several other solutions in mind to solve this "problem".
A serializer specific cache_key class method, that would enable us to configure the used cache_key per serializer.
Extending the serializer specific addons to also get model instance passed into the block.
I did not choose them because from my point of view they have one major draw back, that is:
They are hard to reason about in an inheritance chain of serializers (which I think is even with a simple setup, at least 3 classes deep, MySerializer < MyBaseSerializer < CacheCrispies::Base). It is not really clear if such a configuration would be inherited or not.
I also did not chose to extend the addons block feature because it takes a single positional argument currently (options) and passing it the model as second positional parameter would not be consistent with the rest of the API (show_if etc..). Would be a little challenge to make this change backwards compatible and consistent with the current api (probably something to consider for a major release?).
Another reason is, I don't think it is neither necessary nor a good thing to animate developers to use different methods on different models to generate the CacheCrispies cacheable.cache_key.
With the chosen solution it would be possible to enhance it to support a Proc as the cache_key_method that is called and gets passed the options and the model instance.
Hi there,
we have the case currently, that the hard coded call to
cacheable.cache_key
in thePlan
is not outdating our cache when we update a model. The reason is, that theModel#cache_key
value does not change after the model is updated, which is correct behavior for Rails >= 5.2 since thecache_key
method should be used to for "recyclable" cache keys.Cache versioning is disabled by default for Rails 5.2, >= 6.0 (
ActiveRecord::Base.cache_versioning = false
). Cache versioning is enabled by default for Rails >= 6.0 (ActiveRecord::Base.cache_versioning = true
).See https://api.rubyonrails.org/v5.2/classes/ActiveRecord/Integration.html#method-i-cache_key
I opened this PR for a few reasons instead of just overwriting
cache_key
on my models:cache_key
that I'll probably need in another place.cache_key
tocache_key_with_version
in a future major release.I had several other solutions in mind to solve this "problem".
cache_key
class method, that would enable us to configure the usedcache_key
per serializer.addons
to also get model instance passed into the block.I did not choose them because from my point of view they have one major draw back, that is: They are hard to reason about in an inheritance chain of serializers (which I think is even with a simple setup, at least 3 classes deep,
MySerializer < MyBaseSerializer < CacheCrispies::Base
). It is not really clear if such a configuration would be inherited or not.I also did not chose to extend the
addons
block feature because it takes a single positional argument currently (options
) and passing it themodel
as second positional parameter would not be consistent with the rest of the API (show_if
etc..). Would be a little challenge to make this change backwards compatible and consistent with the current api (probably something to consider for a major release?).Another reason is, I don't think it is neither necessary nor a good thing to animate developers to use different methods on different models to generate the CacheCrispies
cacheable.cache_key
. With the chosen solution it would be possible to enhance it to support aProc
as thecache_key_method
that is called and gets passed the options and the model instance.