ValkeyCache' object has no attribute 'decr_version'

[jmichalicek]

django-valkey version: 0.3.1
django-version: 5.2.7

django-valkey does not currently implement the full interface of BaseCache which can cause compatibility issues with 3rd party packages, for example the popular Django Debug Toolbar which is where I ran across this problem.

The cache backends provided here are pretty out of sync with Django's BaseCache, with the sync and async backends split up and not supported by a single backend, and several methods not implemented.

Locally I have done this and it is working with very basic usage and testing.

from django.core.cache.backends.base import BaseCache

from django_valkey.cache import ValkeyCache


class FullValkeyCache(ValkeyCache, BaseCache):
    pass

[amirreza8002]

hi
the older versions inherit from BaseCache
we parted ways because that structure makes maintenance a pain
also limits us from a fair bit of development

about providing all the methods, I'll have to take a look.
I'll report back the results

[amirreza8002]

ok by my cound the olny thing we need to add is decr_version
i'll add that then

if there is something i'm missing, please inform me🙏

[jmichalicek]

@amirreza8002 Thanks for adding that!

I am going to suggest that at least for the sync backend subclassing BaseCache is likely to save you work and ensure compatibility with the expected interface in the end even with keeping your current separation of the implementations. It's reasonable for any third party package to expect all of the methods to be there.

For this case as an example, by having subclassed BaseCache, while leaving the rest of your implementation as is, ValkeyCache would have already had the decr_version() on it. The implementation of it provided by BaseCache also would have worked without you needing to add your own decr_version() methods anywhere. It just calls self.incr_version() with a negative number, so that would have called ValkeyCache's incr_version() which would have then called self.client.incr_version() in the same way the decr_version() you wrote and have to put in two places does. I believe there are a couple of others where you would benefit from having to implement less code in the same way.

It would also result in all of the methods like aadd(), aincr_version(), etc. being there to satisfy the interface and, as far as I can tell, would be functional. Those all just use the sync_to_async() wrapper to call the sync versions of the methods.

[amirreza8002]

sorry for the delay
this method is now avilable as 0.3.2 in pypi

[amirreza8002]

about using django's base class,
i've raised the discussion on changing the structure to support both sync and async (native async, not sync_to_async)
but so far, there isn't much interest in the topic

having both sync and async methods in one class was a painful expirience for django-valkey and took me a very long time to get this package out of it
there might be a few problems here and there, but i think it's worth it, it general