-
Notifications
You must be signed in to change notification settings - Fork 47
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
KeyType might not always be str
#242
Comments
well the API is just the interface that allows I can see some kind of hashable object as a key but not a tuple of strings, we have a separate API get_multi() for that. redis is a full fledged datastructure database, but dogpile's use of it as a "cache" is just one particular application. I wouldn't use dogpile for open-ended redis work. |
I'm trying to think of what might work. For reference, a call in the redis client would be :
which would return the value stored in a python object equivalent to:
i've typically used a tuple to define this key as
redis hashes are often used to aggregate logical groupings of items, or minimize memory footprints by shortening the key lengths. we use it with dogpile for both. |
dogpile.cache.api defines
KeyType: str
https://github.com/sqlalchemy/dogpile.cache/blob/main/dogpile/cache/api.py#L44-L45
Redis offers a hash/dict mapping for storage, which is accessible using the
.hmget
/.hmset
methods from redis-py. The current backends do not support this, but third-party/developer backends and proxies do.I'm not sure of the best way to support this for developers and potential future usage. The only thing i can think of is to extend
KeyType
toUnion[str, Tuple[str]]
.The text was updated successfully, but these errors were encountered: