Runtime: How to get the list of keys using IDistributedCache extension.

[RajivPandi]

Is there an extension method available to get the list of keys from the cache.
I am using Redis Cache provider, i can able to get the list of keys matching the patter using Redis CLI. I am looking for similar feature using IDistributedCache.

[chuanboz]

+1 for this request. Any plan to add this support in the near future?

[stefankip]

Too bad nobody cares to help is with this 👎

[skironDotNet]

You could write your own. I know not a good answer but I'm looking for same thing, so I'm going to have my instance of IDistributedCache where I pass original IDistributedCache and low level Redis client, then will have a method to get keys, keeping ready features of IDistributedCache like sliding expiration management.

Saying all that I'm supprised MS, didn't make this by deafult like KeyExists() or didn't expose Redis client as a property of IDistributedCache so it would be super easy to write extensions to use every feature of Redis.

[dropsonic]

It is a very important feature indeed.
In my scenario, I have some features in every cache item (e.g., locale, username, etc.), and I want to invalidate the cache by a specific feature (e.g., invalidate all cache items where locale = "en-US").
It is impossible to do with the current interface.

@skironDotNet exposing Redis client is not a good idea because IDistributedCache hides implementation details from you. It might be Redis, but it also might be SQL or in-memory cache so you cannot use Redis-specific details.

[maryamariyan]

I believe this would be a new feature request.

cc: @Tratcher @eerhardt

[Tratcher]

Yes this would require new APIs. We've decided against this in the past for both IDistributedCache and IMemoryCache because of the ephemeral nature of cache entries. An entry name might be returned in the list, but then be removed and/or replaced before you could request it.

[eerhardt]

We've decided against this in the past for both IDistributedCache and IMemoryCache because of the ephemeral nature of cache entries.

My thinking is that we could return a "snapshot" of the keys in the cache at the point in time you ask for them. There wouldn't be a guarantee that the key would still exist (or have the same value) after the call. The idea being you could use this new API in conjunction with #36568, to allow users to remove many entries in a single call. Given the snapshot, they can look through them (maybe apply Regex or StartsWith or similar), and build up a list of the entries they want to remove. This seems to be a pretty popular scenario - we saw a handful of issues discussing this same thing.