-
Notifications
You must be signed in to change notification settings - Fork 3
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
Expose object subcommands in RedisCache #5
Comments
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 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 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. |
I'm planning on including 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. |
Object subcommands such as refcount are currently only available through the underlying aioredis Redis object
The text was updated successfully, but these errors were encountered: