Hey Adam and Andrew,
I can definitely make the naming scheme something like get_async() rather than just get().
> 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'm slightly confused by what you mean (and what the dep means). Are you saying in case someone is using a built-in cache backend like LocMem for local development and then an async third-party cache backend for production, then the code is like:
class BaseCache:
def get(...):
NotImplementedError
async def get_async(...):
NotImplementedError
class LocMemCache:
def get(...):
...
async def get_async(...):
return await asgiref.sync_to_async(self.get)(*args, **kwargs)
> It could be informative to have a working backend using this interface, and if you encounter any edge cases whilst creating it.
You can view my progress (once midterms are over :P)
over here. I'm planning on making the structure very similar to django-redis to make any migration process to an async Django easier. When I compared redis-py to aioredis, there weren't that many differences besides file structure (and passing the event loop around), so hopefully nothing weird pops up. But I will definitely post in this thread or in a ticket (if I do make a PR for BaseCache) if something odd does pop up.
> 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
In terms of the package or the other built-in backends or just everything in general like the ORM? If in terms of the package, most if not all methods would have to be awaited... I could also just be confusing all these words, so sorry about uhh me I guess!
Thanks for the suggestions! Have fun with the ORM!
Andrew