alastairtree
commented
3 years ago Hi thanks for this. The challenge with accepting this is that I imagine all operations against the cache will now take around twice as long because there are effectively 2 caches to maintain. There are some benchmarks in the project that could be used to demonstrate this. In addition if an item in the cache expires due to age I don't think it will be removed from the list of keys uoi added? So potentialy the list of cache keys could grow forever? Based on the current design of your implementation I don't think it would be possible to accept a PR like this.
I've read numerous requests to have a better mechanism to enumerate through keys that are stored in cache. This makes it very convenient to expire an entire set of cached items based on a prefixing pattern. While I understand there are various other ways to achieve this (like using cancellation tokens, or multiple caches) having access to a dictionary of keys makes for a very simple implementation.
Internally this maintains a ConcurrentDictionary with all of the cache keys, and a metadata object about each cached item. When calling
GetCacheKeys()you get a copy of the key dictionary at a point in time. It's fully possible that a separate process changes the dictionary after the copy is taken. If the caller needs to prevent the dictionary from being modified while consuming the key dictionary that locking could be added external of LazyCache. For many use cases that level of control wouldn't be needed.I've also added tests to demonstrate the dictionary working properly.