Closed rzepinskip closed 2 years ago
Hi,
I am curious whether you have explicitly decided not to support batch methods (if so what are the reasons - implementation burden / other patterns to use / no need etc.) or is it planned for the future?
Good question!
The project was born as an abstraction layer on top of the standard IMemoryCache and IDistributedCache interfaces, so the operations available are the ones available on those interfaces + the ones I felt added value (like the atomic GetOrSet, the GetOrDefault, etc) that - while not available there - maintained the same access pattern (eg: one entry at a time).
Do you already have an idea about how those methods would be modeled?
Like I can imagine instead of a single string key
it would accept an IEnumerable<string> keys
, but what would be the shape of the factory? And what would the method return, a Dictionary<string,TValue>
or something else? Also we should think about a factory failing for a single entry while for the others succeed (in case the impl is a series of single GetOrDefault because the underlying cache can't handle multi-get), how should we handle that?
If you have any suggestion in this regard I'd be happy to know.
As of today the need for multi-key methods did not came up, but I'm open to explore that and put it in my backlog, which by now contains adding support for events #14 , a plugin system #15 (which combined will hopefully lead, with the kind help of @joeshook , to the support of metrics #9 with multiple providers) and a distributed backplane #11 .
BTW. Neat project ;)
Thanks 😁 !
Any suggestion about any aspect (docs, etc) is more than welcome.
It is mainly a performance improvement when underlying service (endpoint) supports batch requests. GetOrSet
and factory method could follow the same interface: accept IReadOnlyCollection<string>
and return IReadOnlyDictionary<string , TValue>
. Failure for a single entry when cache does not support batch request may be signaled by AggregateException
but using such cache for batch requests probably should be discouraged.
I'm moving this to the recently opened Discussions board.
In case this will be approved to become a feature a separate issue for the design & development will be created.
Hi,
I am curious whether you have explicitly decided not to support batch methods (if so what are the reasons - implementation burden / other patterns to use / no need etc.) or is it planned for the future?
BTW. Neat project ;)