#32092: Add an async db backend: asyncpg
-------------------------------------+-------------------------------------
Reporter: Andrew Chen Wang | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: database | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Andrew Chen Wang:
Old description:
> This ticket wishes to add an asynchronous DB backend, namely using
> [https://github.com/MagicStack/asyncpg asyncpg].
>
> I've recently finished porting
> [https://code.djangoproject.com/ticket/32076 Django's cache to use async
> methods] in an async context. I'm continuing along my opinion that we
> need to have the layer of the cake down, i.e. the cache and the db
> backends, before the rest of the async porting of Django can continue.
> Thus, I'd like to begin getting an async database backend as well using
> asyncpg for a future async Django ORM along with async template loading
> (since psycopg3 is not complete).
>
> I don't have much experience with the ORM itself, but I'd like to get the
> work started. One of the reasons this hasn't been started grandly is
> mentioned in DEP 9:
>
> > A lot of this stems from the fact that the underlying database drivers
> are synchronous
>
> [https://github.com/django/deps/blob/master/accepted/0009-async.rst#the-
> orm from here] and because Andrew, not me, is pretty busy lately. I think
> I can alleviate some of the workload by implementing this backend as a
> way to get started testing an async ORM.
New description:
This ticket wishes to add an asynchronous DB backend, namely using
[https://github.com/MagicStack/asyncpg asyncpg].
I don't have much experience with the ORM itself, but I'd like to get the
work started. One of the reasons this hasn't been started grandly is
mentioned in DEP 9:
> A lot of this stems from the fact that the underlying database drivers
are synchronous
One thing that must take place before this ticket starts any code is the
design decision. Don't know how to cc people, but I'd like to know what
the design decision would be? Unlike `cache.get_async`with that `_async`
suffix, I feel like BaseDatabaseWrapper should just be duplicated into an
AsyncBaseDatabaseWrapper? It wouldn't be DRY, so I'd love to know some
thoughts!
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32092#comment:1>
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/074.7a7c1de86447e6a96ce074d2cb244f80%40djangoproject.com.
