[Question] Reuse decorator settings + Race Conditions

[Wyko]

I'm trying out this package for the first time today, and I'm trying to understand some things. I'd appreciate the answer to the following:

1. Is there any way to set class defaults for the cached decorator so that I don't need to set the parameters each time I use it? I didn't see anything in the examples for this.
2. Is there any potential for race conditions when using any of the different cache options? I saw that the simple memory option had the interesting caveat about mutable objects, which makes me wonder.

Thanks!

[Dreamsorcerer]

• Is there any way to set class defaults for the cached decorator so that I don't need to set the parameters each time I use it? I didn't see anything in the examples for this.

functools.partial()?

• Is there any potential for race conditions when using any of the different cache options? I saw that the simple memory option had the interesting caveat about mutable objects, which makes me wonder.

What kind of race condition? Redlock seems to have a race condition with memcached (#587).

[Wyko]

Regarding the first point, I found the caches.set_config option which helps define common settings. It wasn't entirely obvious via the docs, but another issue here clarified that I could use it for the decorator as well via an alias.

The second question was more broad, and I don't know the answer to "what kind of race condition." Just any time that I have potentially multiple access to a shared data storage, I have to ask the question of whether it's dangerous or not. I know that asyncio is much safer to use with shared variables than threading, but since the datastores here are external to the active process I want to make sure it's still safe.

[Dreamsorcerer]

Regarding the first point, I found the caches.set_config option which helps define common settings. It wasn't entirely obvious via the docs, but another issue here clarified that I could use it for the decorator as well via an alias.

Right, to configure caches, you can do that. I'd like to remove the whole config thing in 1.0 though, instead requiring the cache object to be passed to the decorator (instead of a name).

Just any time that I have potentially multiple access to a shared data storage, I have to ask the question of whether it's dangerous or not.

Well, what's going to be dangerous? If you have a race condition where you are fetching a cache item and saving a cache item, then you either get the old item or the new item. What's going to break in that case? What I mean, is that a race condition depends on what your application expects to happen. If you only use get()/set(), then it's just a simple get or set command which should be atomic in any backend. If your application depends on the order of get/set then you'd want to introduce locking or something in the application.

As I said before, the only unexpected race condition I'm aware of is the redlock behaviour in memcached, which is a bug rather than something you should be dealing with yourself.

[Wyko]

Thanks!

As a side note, is there anything I can configure now already as a transition from the old to the new config methods? Does passing it as an object work already or are you still pending making that behavior?

[Dreamsorcerer]

Not currently, I'm not sure it'll be easy to make it backwards-compatible. The change is tracked in #609.
Best thing you can do now is to setup mypy and use static typing. When 1.0 is released, it will include type annotations (it's pretty much impossible to do type annotations in the 0.x release), so you'll get type errors with your old code. Details will also be in the changelog.

Contributions are welcome, so if you'd like to work on something, there are several pending tasks for 1.0.