Changes between Version 1 and Version 2 of Ticket #32076, comment 7
- Timestamp:
- Oct 7, 2020, 12:34:17 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #32076, comment 7
v1 v2 1 1 > The cache closing problem is a bit larger, though 2 2 3 I wanted to put this in a separate comment because, while writing my PR comment, the issue of adding async cache to Django might be larger but this ticket is important in order to start porting the rest of Django to async. Lots of things like the SessionCache backend and generally closing the cache using Signals requires adding a lot of code; without those async methods i.e. this ticket, we can't actually implement the code that uses the cache.3 I wanted to put this in a separate comment because, while writing my PR comment, I realized the issue of adding async cache to Django might be larger but this ticket is important in order to start porting the rest of Django to async. Lots of things like the SessionCache backend and generally closing the cache using Signals requires adding a lot of code; without those async methods i.e. this ticket, we can't actually implement the code that uses the cache. 4 4 5 5 To me, if DEP 9 is to implement Django templates, middleware, signals, etc. as asynchronous, the base layer of the cake needs to be set first: that means getting the cache and database access ready beforehand. 6 7 Edit: So in essence, I think this ticket can at least cover getting the BaseCache ready for future usage of async. Perhaps instead of raising a NotImplementedError like what felixxm said, then I can change that for `sync_to_async` usage so that when a Django version upgrade happens, then those using something like FileBasedCache are not immediately given huge errors. I've got LocMem down in a separate commit, but I definitely won't be handling all Django cache backends.