Add cache_store adapter for caching via ActiveSupport::CacheStore #265
Conversation
* Helpful adapter for Rails users that want to use their configured cache.
I think because not all methods support the same options, I would be inclined to be explicit about the options we support and where we support them. TTL/expires seems like the most sensible one to support out of the gate. Any other obvious ones to support?
I don't understand this part. I don't see |
I would be inclined to be explicit about the options we support and where we support them I don't see fetch_all in the PR. |
It looks like no need for the custom read_multi nonsense I mentioned above. Cache implements this and caches (such as MemoryStore) can implement it themselves if they want to optimize it. So we're all good there, if the cache doesn't implement it it will just fall back to this default implementation via the looping read(). https://github.com/rails/rails/blob/master/activesupport/lib/active_support/cache.rb#L353 |
b2f56af
to
0087b4e
* Before we accepted all options passed them onto the cache methods, but this allows us to be more specific * use a write_options hash since we don't want to override the default expires_in if its already been set on the cache instance
@name = :cache_store | ||
@cache = cache | ||
@write_options = {} | ||
@write_options.merge!(expires_in: expires_in) if expires_in |
AlexWheeler
Jun 9, 2017
Author
Collaborator
ActiveSupport::Cache will use ttl set on the @cache
getting passed into this initializer, but allows you to set a ttl for a given key when using fetch/write. Doing it this way we won't clobber the already set ttl, but still allow users to use a different ttl for flipper queries.
Its also possible that users won't even want to use a different ttl here and will always want to use whatever they're cache store is using when they initialize it?
ActiveSupport::Cache will use ttl set on the @cache
getting passed into this initializer, but allows you to set a ttl for a given key when using fetch/write. Doing it this way we won't clobber the already set ttl, but still allow users to use a different ttl for flipper queries.
Its also possible that users won't even want to use a different ttl here and will always want to use whatever they're cache store is using when they initialize it?
The other options described here are: and I don't think it makes sense to let users set these at the moment just for flipper stuff. :namespace can be set as well, but we don't want to change the namespace they've already set on their cache store! Instead flipper keys will have their own namespace tacked on the same way the other cache adapters work. |
Looks good! I agree on waiting to add the other keys. |
#263
http://api.rubyonrails.org/classes/ActiveSupport/Cache/Store.html
From docs ^ Some implementations may not support all methods beyond the basic cache methods of fetch, write, read, exist?, and delete. Sinc we're using fetch_all we might want to check if the
@cache
responds to fetch_all and if not then call our own fetch_all that loops with fetch. Thoughts?