Opened 3 years ago
Last modified 5 weeks ago
#33573 assigned New feature
Add native async support to redis cache backend — at Version 5
Description (last modified by ) ¶
The latest version of redis-py will support both sync and async clients so sync_to_async will no longer be necessary so it would be nice if the out of the box Redis cache backend supports both natively as well.
https://github.com/redis/redis-py/releases/tag/v4.2.0rc1
It may be a bit premature since 4.2.0 is still RC, but I wanted to get a ticket out there so it can be on someones radar.
According to the ticket's flags, the next step(s) to move this issue forward are:
Unknown. The Someday/Maybe triage stage is used to keep track of high-level ideas or long term feature requests.
It could be an issue that's blocked until a future version of Django (if so, Keywords will contain that version number). It could also be an enhancement request that we might consider adding someday to the framework if an excellent patch is submitted.
If you're interested in contributing to the issue, raising your ideas on the Django Forum would be a great place to start.
Change History (5)
comment:1 by , 3 years ago
| Cc: | added |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 3 years ago
| Triage Stage: | Accepted → Someday/Maybe |
|---|
Let's wait for the final release first.
comment:3 by , 3 years ago
We are currently re-implementing the async client (one last time) in a way that allows for aioredis 1.3.1 performance. https://github.com/seandstewart/redis-py-sansio/blob/main/benchmark/conftest.py The RedisLab team will need to approve it first, so I would wait until our new client is either approved/denied https://github.com/redis/redis-py/issues/2039. This won't affect the non-async client as the non-async client will still default on the current redis-py interface with the option to also use the new API.
This isn't to say no one should try implementing the async client now; I have high confidence the new client will be merged in with Redis-py as we're gunning for the much-needed performance gain. Just don't be surprised if a few things shift around.
comment:4 by , 3 years ago
| Description: | modified (diff) |
|---|
comment:5 by , 3 years ago
| Description: | modified (diff) |
|---|
Do you have an idea for implementation? As far as I'm aware this would require initializing two redis clients: async and non-async.
I kind of started to implement it, but then realized it was likely going to be a bigger issue then I though. But there is already an abstract RedisClient class that is a wrapper around the base redis.Redis class. It maintains connection polls and handles all of the core commands. It has methods for get, set, add, touch, incr that just calls get_client and makes a new client using the existing connection pull any time it is called.
For Async we can just add something like get_async_client and follow the same pattern within the class. I believe the connection poll should be able to be reused between the sync/async clients, but I am not an expert on Redis.
Tentatively accepted. Do you have an idea for implementation? As far as I'm aware this would require initializing two redis clients: async and non-async.