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

Magic value (-1) for cache TTL is not compatible with cachelib RedisCache. #80

Open
kallqvist opened this issue Jun 19, 2019 · 0 comments

Comments

@kallqvist
Copy link

Hi all!

This is maybe more a feature suggestion than an actual issue, please bear with me and I'll explain my case.

Since werkzeug cache is now deprecated and refactored to a separate library (cachelib) I have started using the RedisCache from that library instead of configuring it through werkzeug internals the way that jobtastic is currently expecting.

So far so good; I figured out the WrappedCache class and how to use that together with cachelib RedisCache and at first glance all is working.

Now here's my issue: I want to have cached results that never expire in Redis.
To achieve that with cachelib RedisCache one would send a TTL of -1 but in jobtastic however a TTL of -1 means "don't cache anything at all, ever" and hence nothing happens.

https://github.com/PolicyStat/jobtastic/blob/master/jobtastic/task.py#L353
https://github.com/pallets/cachelib/blob/master/cachelib/redis.py#L95

I get that we can't just change this magic value in jobtastic to mean the complete opposite of what it means today for backwards compatibility reasons but I guess the same could also be said about cachelib...

One solution I could imagine happening in jobtastic would be moving the "what does a TTL of -1 mean?"-logic out from the middle of run() and instead deal with it in it's own function that we somehow could override in base classes and change.
Maybe just like a "determine_ttl()" or perhaps a larger "dispatch_set()" function to optionally override with slightly more responsibilities.

Preferably for future compatibility purposes I also don't want to override the entire run()-function in my project to achieve this fairly tiny change in logic.

Another option I guess would be to have a config value of sorts in jobtastic to determine if -1 should mean never or always?

Do you have any thoughts on this?

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

1 participant