KeyType might not always be `str`

[jvanasco]

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 to Union[str, Tuple[str]].

[zzzeek]

well the API is just the interface that allows CacheRegion to use it for a backend, and CacheRegion uses strings or single objects for keys.

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.

[jvanasco]

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.

I'm trying to think of what might work. For reference, a call in the redis client would be :

result = r.hmget("a", "0")

which would return the value stored in a python object equivalent to:

 result = datastore["a"]["0"]

i've typically used a tuple to define this key as ("a", "0").

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.

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.