#33573: Add native async support to redis cache backend
-------------------------------------+-------------------------------------
Reporter: Christopher Bailey | Owner: nobody
Type: New feature | Status: new
Component: Core (Cache system) | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Andrew Chen Wang):
It doesn't seem like the Sans-IO approach will be adopted anytime soon as
work and review has stalled.
> I believe the connection poll should be able to be reused between the
sync/async clients, but I am not an expert on Redis.
Sorry if I misunderstood, but the ConnectionPool classes for the sync and
async versions are different, and the Connection classes are also
different.
> As far as I'm aware this would require initializing two redis clients:
async and non-async.
Assuming you mean initialize `redis.Redis` and `redis.asyncio.Redis` in
one class, I disagree; I think we should have two RedisCache classes, one
for sync and another for async.
1. Some users may want both a sync and async Redis client. However, the
options presented to devs cater to only one of the variants. For instance,
if you need to pass in a custom ConnectionPool or provide pool options for
the default pools, those could be different for the different environments
like an async enabled middleware uses the async Redis but a sync view uses
the sync Redis. If a custom Connection class is provided to the pool, then
we'd have a problem since the Connection class for the sync and async
Redis are different.
2. The actual network calls like `get` and `set_many` look like they will
be copy-paste because of the numerous awaits required, so there won't be
much if any re-use of code
3. Not all clients have upgraded to at least Redis 4.2.0.
4. It sets a paradigm for future client implementations. Regardless of
whether packages like psycopg(3) implement both a sync and async variant
or just one type like the memcached packages implementing just sync, there
should be a separation of clients based on environment to set future
expectations of clients not necessarily having a counterpart variant like
an async package not having sync support.
Let me know your thoughts. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/33573#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070185697ac569-c049724e-b69a-4352-b601-b55595a62776-000000%40eu-central-1.amazonses.com.
