Agreed - there's no work on caching inside Django yet, since the ORM is my next 
focus, but I would definitely suggest writing a new pluggable third-party 
backend that somehow provides async versions of the methods.

The main work to do here is to work how quite how possible it is to offer all 
of them and if everything can be made to work regardless of what mode (sync or 
async) it's in; hopefully there's a lot less long-lived-connection issues than 
in the ORM, say.

Andrew

On Sat, Sep 26, 2020, at 3:56 PM, Adam Johnson wrote:
> Hi Andrew
> 
> I don't believe any work has started on async caching in core. However there 
> is a plan in DEP 9, the document that outlines how asynchronous caching will 
> work, using suffixed methods like get_async() etc. See 
> https://github.com/django/deps/blob/master/accepted/0009-async.rst#caching . 
> This section specifically says that the default implementations will back 
> onto the sync methods by default, so built-in cache backends won't need to 
> all be converted (at once?).
> 
> I think a good start would be making your aioredis-based backend in a third 
> party package, using the future naming scheme `*_async`. It could be 
> informative to have a working backend using this interface, and if you 
> encounter any edge cases whilst creating it.
> 
> Thanks,
> 
> Adam
> 
> On Sat, 26 Sep 2020 at 05:55, Andrew Wang <acwangpyt...@gmail.com> wrote:
>> Hey guys, I'd like to contribute to the effort to make Django more async 
>> capable. I've started to write an aioredis based cache backend based on 
>> django-redis, but I noticed the BaseCache in Django is still all synchronous 
>> basically.
>> 
>> I was wondering which backends I should make async capable and how would I 
>> go about it?
>> 
>> I was thinking instead of creating a new class, we could just add the async 
>> methods (e.g. add, get) to BaseClass. And for the FileBased, Dummy, and 
>> LocMem backends, the plan would be the same? Problem with those are Python's 
>> local file IO is synchronous...
>> 

>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/68307bf9-e6f4-4dc3-9e0f-d6e660075a85o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/68307bf9-e6f4-4dc3-9e0f-d6e660075a85o%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> Adam
> 

> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM00ourgfJs53v7NmXOGEV6_t8vV3%3D%2BP%2Bf61DHEhOcFvDw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM00ourgfJs53v7NmXOGEV6_t8vV3%3D%2BP%2Bf61DHEhOcFvDw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2efe271c-2626-45a9-a6f0-bd808562b2a2%40www.fastmail.com.

Reply via email to