async-rediscache
async-rediscache copied to clipboard
Expose object subcommands in RedisCache
Object subcommands such as refcount are currently only available through the underlying aioredis Redis object
Could you elaborate on what you have in mind?
The current design is that this package provides convenient data types to work with, which are "incidentally" backed by redis for persistence. The types currently implemented and planned for the future are not meant as "thin" wrappers around the redis data types. For example, the RedisCache
is not just a thin wrapper around a Redis hash data type (although it uses a Redis hash for its persistence).
The problem with exposing the underlying methods is that it is really easy to leave the underlying storage in a state that's not consistent with the design of our data types. Our data types "remember" types by using "typestrings", which means that if you set a string value, it gets stored with a type prefix to ensure that the type you get "out" is the same as the type of value you put "in" to a data type.
Rather than exposing the underlying implementation details, I'd rather add functionality that makes sense in the context of the data types provided by this package. If what you need is a different type, feel free to make a suggestion for a different data type. If you instead want to use a redis hash data type, my recommendation is to use aioredis
and use a redis hash type directly.
If there are specific features you think fit the existing data types, feel free to suggest them, though.
Ah, I didn't realise that these would only work on the top hash and not its keys where we actually store the data. You mentioned some kind of rewrite on discord, what would that involve? Currently not having access to things like idletime and key expires limits the usability of the package as a more complex cache (setting on every get is a bit redundant when redis has the functionality in an another type), is this out of scope for now or would the rewrite allow it?
I'm planning on including expiry
in the future. I'm already using myself in another project (the advent of code leaderboard cache in python-discord/sir-lancebot has an expiry set with the underlying connection). As discussed above, it would only work on an entire RedisCache at once because of Redis limitations.
I guess we can also expose the underlying connection more easily (it's currently accessible using a marked-as-private attribute), but manual operations could lead to corruption of the underlying data structures more easily.