Closed ndrwrbgs closed 3 years ago
What do you mean with "the cache was used in a previous execution"? If you talk about a distributed cache, yes, stats will never be even remotely reliable. Even if you would set an initial count, Redis could decide to evict items based on memory caps or someone could manually remove keys and then the count would not match anymore. The cache might also not be used exclusively by your code or multiple instances of the code might add items and each instance will eventually have a different count.
Long story short, stats are not meant to be used for any business logic and might not be very accurate in certain scenarios. And setting the count at the beginning might also not really help, so, not sure how useful this would be. But I'll have a look if there was another reason I had to make that object so internal ^^
@MichaCo yes, in distributed caches I would expect this property to not represent the size of Items in the underlying cache. How to handle those other scenarios I'd have to defer to your expertise.
My scenario is on disk caching for developer-time productivity or single-box tools. In such cases, we can see the number of items in the cache which would be a useful proxy for how much space we are taking/if eviction is working properly -- things like that. Since my provider is SQLite, getting the count of items already in an existing cache file is very simple and I'd like to report it via the Performance Counters for collection and monitoring of the system across-executions.
I know my case is unique (in memory cache will always have accurate item count tracked purely by Adds/Removes, distributed cache will maybe never have accurate Item count), but I was hoping for a way to pass the information without resorting to brittle reflection :-) If you don't see the use case as useful enough, I can unblock myself with reflection, but I'd really like to champion this library as not only for production distributed cache scenarios, but also data extraction/tooling/analysis scenarios and this would help!
Some handles have an existing count of
Items
before anything is added (e.g. if the cache was used in a previous execution). The solution for this issue would be to support some way of setting or signaling toCacheStats
that Items has a value already.Solutions tried: Since
.Stats
is virtual, I tried to override that with another class/implementation that would setItems
, butCacheStats
is the required type and is sealed, and externally (even in the ctor) doesn't enable setting the item count.Work around: I can use reflection to set the value I need
Request: Provide a ctor that enables setting initial
Items
count, or some way for aCacheHandle
to set theItem
count directly via a method