You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docs say your Django cache backend adds a convenient .lock(...) function (which is great). But we need to use a dummy cache backend in some cases (e.g. building a Docker image or running tests) when no Redis service is available or otherwise necessary.
If our application code uses this convenient .lock(...) function, it will break when we switch the backend to Django's provided dummy cache backend unless we program defensively around every usage.
With the normal dummy cache backend, I think it just never returns a hit. With a dummy .lock(...) function, I suppose it should always successfully acquire a (dummy) lock?
The text was updated successfully, but these errors were encountered:
I'd expect implementing a dummy backend is something that you could easily do in your own app. A class with a method that returns dummy context manager basically.
If I'd have such a thing here then people will have pointless requests like "make it use local memory or whatever" and get confused about it.
@ionelmc Fair enough. Maybe a short note in the docs then to explain that if you make use of this additional function, you won't be able to simply swap out your cache backend for another, and your suggestion above of making your own dummy cache backend if needed?
This wasn't immediately obvious to me (but should have been, I admit) until I hit an exception, and then I went looking in the code/docs for an API compatible dummy cache backend in python-redis-lock.
The docs say your Django cache backend adds a convenient
.lock(...)
function (which is great). But we need to use a dummy cache backend in some cases (e.g. building a Docker image or running tests) when no Redis service is available or otherwise necessary.If our application code uses this convenient
.lock(...)
function, it will break when we switch the backend to Django's provided dummy cache backend unless we program defensively around every usage.With the normal dummy cache backend, I think it just never returns a hit. With a dummy
.lock(...)
function, I suppose it should always successfully acquire a (dummy) lock?The text was updated successfully, but these errors were encountered: