Skip to content
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

Open
Numerlor opened this issue Oct 11, 2020 · 3 comments
Open

Expose object subcommands in RedisCache #5

Numerlor opened this issue Oct 11, 2020 · 3 comments

Comments

@Numerlor
Copy link
Contributor

Object subcommands such as refcount are currently only available through the underlying aioredis Redis object

@SebastiaanZ
Copy link
Owner

SebastiaanZ commented Oct 12, 2020

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.

@Numerlor
Copy link
Contributor Author

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?

@SebastiaanZ
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants