Since #1014, mget and mset in cache-manager delegate to the Keyv store's getMany/setMany, so bulk-capable adapters (e.g. @keyv/redis) use a single native command. mdel was not included: it still loops the key list calling store.delete(key) per key, costing one round-trip per key.
As noted in #1014: "we will have getMany, setMany, hasMany, and deleteMany. These should all be aligned."
Proposal: align mdel with the mset pattern — stores.map(async (store) => store.deleteMany(keys)). Keyv's deleteMany already falls back internally for adapters without native support, so no fallback logic is needed in cache-manager. Behavior otherwise unchanged (nonBlocking, events, return value).
Happy to submit a PR with tests and a benchmark.
Since #1014,
mgetandmsetin cache-manager delegate to the Keyv store'sgetMany/setMany, so bulk-capable adapters (e.g. @keyv/redis) use a single native command.mdelwas not included: it still loops the key list callingstore.delete(key)per key, costing one round-trip per key.As noted in #1014: "we will have getMany, setMany, hasMany, and deleteMany. These should all be aligned."
Proposal: align
mdelwith themsetpattern —stores.map(async (store) => store.deleteMany(keys)). Keyv'sdeleteManyalready falls back internally for adapters without native support, so no fallback logic is needed in cache-manager. Behavior otherwise unchanged (nonBlocking, events, return value).Happy to submit a PR with tests and a benchmark.