-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to get the list of keys using IDistributedCache extension. #36402
Comments
+1 for this request. Any plan to add this support in the near future? |
Too bad nobody cares to help is with this 👎 |
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. |
It is a very important feature indeed. @skironDotNet exposing Redis client is not a good idea because |
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. |
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. |
How is this still not implemented? Disappointed. |
Set milestone to 8.0. Next step here we'll need to prepare API suggestions. |
When you don't dogfood your own code, and basic requirements fall through the cracks for literal years... oof |
But let me decide about what do I do in that case! |
Just give us a Command or Action method. That way, it can be atomic, not a returned list of values, but an action that is performed during the scan at the moment a matching key is found. |
I would urge the team to think less about downstream ramifications of returning keys that may no longer be present and leave that as an exercise to the developer about how to handle the issue. Presumably, we're aware (since we're querying a cache implementation) that we're requesting information about keys whose values are bound to various expiration windows. I would thus propose that the revised API add both a 1) method for listing known, current (at that time, knowing it's a distributed operation and this snapshot may not be perfectly up to date) keys stored in the system making no guarantees about whether they'll be available in a future call or not and 2) a method (e.g. GetCacheItemMetadata or the like) that allows the developer to, given a key, get information about the expiration window for a given cache item, if it is still valid when this call is made. If the expiration information is meaningful to the developer, this gives them an opportunity to do that second round-trip to the implementation to both 1) determine if the entry is still valid and 2) learn how much longer it will be valid for. Otherwise, when requesting a list of keys with no guarantees made about their lifetime after that ask, any calls to get the value would succeed or fail just like any other time I attempt to access a cache entry with a valid or expired key: you don't know until you ask. I don't see any reason to overcomplicate the ask here, but I'd be interested to hear more about why the team thinks such guardrails are necessary here. |
So if I understand correctly, the only way to retrieve multiple cached items by an expression based on the key, is, for now, to know and use the concrete implementation behind the interface for allowing to get all keys which match a certain pattern? |
Is this still not done after 5 years? I guess back to using the IConnectionMultiplexer itself var db = Redis.GetDatabase();
var endpoint = Redis.GetEndPoints().First();
var redisServer = Redis.GetServer(endpoint);
await foreach (var key in redisServer.KeysAsync(pattern: $"{typeof(TEntity).Name}:list*"))
{
await db.KeyDeleteAsync(key);
} |
With a concurrentDictionary and adding deleting in Get and Remove can be done? |
net9-timescale update; we're discussing a range of However: I'll be honest - I'm not a huge fan of "list the keys" APIs; in reality, most times I've seen people use this kind of API: they've been using it inappropriately and in ways that are actively harmful to the system. Key-value stores usually aren't optimized for this scenario if it is even possible at all - they're optimized for "GET {key}" and "PUT {KEY} {value} {expiry}" (in the language of the backend). This usage might make sense for a "database admin / visualization" tool, but it isn't usually something you should use in routine/regular application code, IMO. I will note that Aspire makes it easier to also get to the "real" backend, such as |
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.
The text was updated successfully, but these errors were encountered: