Async and sync methods and BaseCache

[bufke]

Hello,

As noted, the Django base cache backend has a number of methods for sync and async functions. Not all implemented in this project. I'm curious if you have plans on where to take this project with async and sync support.

Sometimes 🙃 these base functions and their sync_to_async a-prefix functions work as intended. A backend can implement the sync version and the async may actually work, at a performance cost. This doesn't always work in the real world, but when it does it means a developer could theoretically slowly implement async. A holy grail of converting projects from sync to async.

I'm curious if you are open to or have thoughts on supporting an async client with sync fallback. I imagine the async client would just get sync versions, which call async_to_sync.

[amirreza8002]

hi
I'm in a bit of hurry so more discussion for later
but I'm curious which method is not implemented?

the ones discussed in issues were my mistakes, so if it's anything left pls let me know

cause as far as i know they are all implemented right now

[amirreza8002]

as a longer answer
i don't currently have any plans to change the async clients

generally having a class that mixes both sync and async methods is not recommended, they do get mixed up a lot and cause problems (as also happened to me in project when they were sharing a class)

what one might think about if they want to slowly convert between sync and async is to configure two clients (one sync, one async) which would look something like this:

CACHES = {
    "default": {
        "BACKEND": "django_valkey.cache.ValkeyCache",
        "LOCATION": ["valkey://127.0.0.1:6379?db=1", "valkey://127.0.0.1:6379?db=1"],
        "OPTIONS": {"CLIENT_CLASS": "django_valkey.client.DefaultClient"},
    },
    "async": {
        "BACKEND": "django_valkey.async_cache.cache.AsyncValkeyCache",
        "LOCATION": ["valkey://127.0.0.1:6379?db=1", "valkey://127.0.0.1:6379?db=1"],
        "OPTIONS": {
            "CLIENT_CLASS": "django_valkey.async_cache.client.AsyncDefaultClient"
        },
    },
}


from django.core.cache import caches
from django.utils.connection import ConnectionProxy


async_cache = ConnectionProxy(caches, "async")  # this is for ease of use, not necessary

hope this helps
also pls let me know if you disagree, i think there isn't enough discussion about async caching in django

[bufke]

Thanks for explaining. I agree that mixing them can cause problems. Django ORM uses both and after years still doesn't truly support async. I wouldn't mind helping to test and try out sync_to_async and async_to_sync. It does make it easier, if it works. The multiple CACHES is a workaround, I presume a tradeoff is we'd presumably end up with two unique pools.

If you want to keep them fully separated, then let's close this issue. If you want me to explore it a bit more I could.

For me personally I'm trying to add true asyncio support to a open source web app where users might provide valkey or use a database fallback. We would benefit from asyncio. But apps like django-allauth don't support async cache. So I have to blend them one way or another. Some of the django cache backends support support both async/sync (in the annoying way where async has no real benefit)

[amirreza8002]

as far as i know the non-cluster clients in valkey-py are lazy
and django closes connections after each request is finished
so having multiple cache backends configured shouldn't be expensive
tho i should clarify that this is not backed with any concrete information

[amirreza8002]

i suppose i could make it easier for people to combine the two
i need to think about it tho

[bufke]

I tried a trivial implementation

from asgiref.sync import async_to_sync
from django_valkey.async_cache.cache import AsyncValkeyCache as UpstreamCache

class AsyncValkeyCache(UpstreamCache):
    def get(self, *args, **kwargs):
        return async_to_sync(super().get)(*args, **kwargs)  # super().aget would make more sense but doesn't work

This is essentially what I see as the ideal feature:

async def test_async_view():
  await cache.aget("foo)   # True asyncio call

def test_sync_view():
  cache.get("foo")   # Slower context switching blocking call that converts the async call to sync

But this errors with You cannot use AsyncToSync in the same thread as an async event loop - just await the async function directly as tested with uvicorn.

I do find it surprising that set returns a coroutine. In Django it's documented as a sync function. I would expect it be blocking or else raise a NotImplemented error.

I hope not to sound complain-y, I'm glad anyone is doing anything at all with async Django 😄

I believe Django ORM does a lot of work to check the context in which ORM calls are made, to ensure the a prefix calls are made only in async contexts and vice versa.

[bufke]

I tried the sync + async CACHES approach some more.

valkey-cli reports the connected clients as two instead of just 1. So there is some impact. It also errors when attempting to combine them like

async foo(request):
  print(cache.get("foo"))
  print(await async_cache.aget("foo"))

object Connection can't be used in 'await' expression. If you comment either one out, it works fine. Weird!

[amirreza8002]

hi

But this errors with You cannot use AsyncToSync in the same thread as an async event loop - just await the async function directly as tested with uvicorn.

i think that's a limitation on asgiref, but i should see the full traceback to know for sure

I hope not to sound complain-y, I'm glad anyone is doing anything at all with async Django

not at all, we actually need more feedback on async backend

I do find it surprising that set returns a coroutine. In Django it's documented as a sync function. I would expect it be blocking or else raise a NotImplemented error.

the underlying library (valkey-py) uses set, whereas django uses aset
at the time i tried to be comaptible with both
i don't if it was the best choice or not :)but it is documented

object Connection can't be used in 'await' expression. If you comment either one out, it works fine. Weird!

if possible please paste the full traceback and configs

[amirreza8002]

i suppose i could make it easier for people to combine the two
i need to think about it tho

after looking around, this would require a rather heavy work and probably a lot of breaking changes

i need to refresh my memmory about async_to_sync, but my vague memmory tells me it won't be useful here

[amirreza8002]

@bufke
hi, sorry to ping

I'm starting to plan a release, if you have a follow up about this, pls let me know so it can be included in the release

[bufke]

Hello, do you still want stack traces? It sounds like it would be fantastic to have get, aget, etc to all just work with sync/async
BUT it would have conflicts with valkey-py get and it would be difficult to get working at all.

If you want my opinion, I think AsyncValkeyCache should be a django cache system first, and a valkey client second. So get should follow Django's sync get call. But that's just my opinion and no one is going to like breaking changes. I'm happy to contribute as best as I can. I would like to push more async friendly solutions in the django ecosystem. There isn't a good django-redis analogy here, because most people would just run get("foo") and it works regardless of if it's passing through to py redis or as a django cache.

[amirreza8002]

if you have them, lets see tarcebacks of the errors you mentioned earlier
we can then decide on other matters i think

[bufke]

I'll make a sample project and copy the traces for you tomorrow. Today is a "day job" day. I was considering trying to add async cache to GlitchTip, which is already very async. I intend to measure the performance improvement, which I expect to be decent compared to uwsgi with many threads. My goal is "more work with less resources".

We must support some sort of end user pluggable cache. Not everything ever, but anything that is sync + async compat friendly. Which ideally lets us target valkey, postgres, or in-memory. I might be willing to write some terrible middleware to fetch the right cache but it would be cooler to fix it upstream.