You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every newly instantiated Keyv cache sets the namespace attribute of the underlying store, which has two implications (at least when using the KeyvRedis backend):
the namespace is duplicated. Redis keys have names like sets:namespace:<namespace>:<namespace>:<key> instead of sets:namespace:<namespace>:<key> (I wonder if we need such a long prefix at all, vs just <prefix>:<namespace>:<key>, where <prefix> can be configured by the user when instantianing the store, but that's a different story...)
it's not possible to safely use the same store for multiple caches, as instantiating a new cache modifies the namespace of the underlying store, which is used to retrieve keys, thus breaking previous stored entries.
How to reproduce
Given this snippet which instantiates two Keyv caches which use the same store (which, in turn, share the same pre-existing Redis connection).
You can see the duplicated namespace and the full key for the address cache entries changing after the professions cache is instantiated.
Suggested resolution
Keyv should not set the namespace of the underlying store at all. Store namespace (or, better, prefix) should be optional and configurable by the user at the store level. This would result in much cleaner redis keys like <store-prefix>:<key cache namespace>:<key>. It would also allow users to configure short prefixes/namespaces to save memory, which can be quite important for redis and other stores where key size is consequential.
The text was updated successfully, but these errors were encountered:
Bug description
Every newly instantiated
Keyv
cache sets thenamespace
attribute of the underlying store, which has two implications (at least when using theKeyvRedis
backend):sets:namespace:<namespace>:<namespace>:<key>
instead ofsets:namespace:<namespace>:<key>
(I wonder if we need such a long prefix at all, vs just<prefix>:<namespace>:<key>
, where<prefix>
can be configured by the user when instantianing the store, but that's a different story...)How to reproduce
Given this snippet which instantiates two Keyv caches which use the same store (which, in turn, share the same pre-existing Redis connection).
Running the script you'll get
Instead of the expected:
And this is the output of redis
MONITOR
command while running the script:You can see the duplicated namespace and the full key for the address cache entries changing after the professions cache is instantiated.
Suggested resolution
Keyv should not set the namespace of the underlying store at all. Store namespace (or, better, prefix) should be optional and configurable by the user at the store level. This would result in much cleaner redis keys like
<store-prefix>:<key cache namespace>:<key>
. It would also allow users to configure short prefixes/namespaces to save memory, which can be quite important for redis and other stores where key size is consequential.The text was updated successfully, but these errors were encountered: