Django has developing support for asynchronous ("async") Python, but does not\nyet support asynchronous views or middleware; they will be coming in a future\nrelease.
\nThere is limited support for other parts of the async ecosystem; namely, Django\ncan natively talk ASGI, and some async\nsafety support.
\nCertain key parts of Django are not able to operate safely in an asynchronous\nenvironment, as they have global state that is not coroutine-aware. These parts\nof Django are classified as "async-unsafe", and are protected from execution in\nan asynchronous environment. The ORM is the main example, but there are other\nparts that are also protected in this way.
\nIf you try to run any of these parts from a thread where there is a running\nevent loop, you will get a\nSynchronousOnlyOperation error. Note that you\ndon't have to be inside an async function directly to have this error occur. If\nyou have called a synchronous function directly from an asynchronous function\nwithout going through something like sync_to_async() or a threadpool,\nthen it can also occur, as your code is still running in an asynchronous\ncontext.
If you encounter this error, you should fix your code to not call the offending\ncode from an async context; instead, write your code that talks to async-unsafe\nin its own, synchronous function, and call that using\nasgiref.sync.sync_to_async(), or any other preferred way of running\nsynchronous code in its own thread.
If you are absolutely in dire need to run this code from an asynchronous\ncontext - for example, it is being forced on you by an external environment,\nand you are sure there is no chance of it being run concurrently (e.g. you are\nin a Jupyter notebook), then you can disable the warning with the\nDJANGO_ALLOW_ASYNC_UNSAFE environment variable.
Jika anda buth melakukan ini dari dalam Python, lakukan dengan os.environ:
os.environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = "true"\nIt is necessary to adapt the calling style when calling synchronous code from\nan asynchronous context, or vice-versa. For this there are two adapter\nfunctions, made available from the asgiref.sync package:\nasync_to_sync() and sync_to_async(). They are used to transition\nbetween sync and async calling styles while preserving compatibility.
These adapter functions are widely used in Django. The asgiref package\nitself is part of the Django project, and it is automatically installed as a\ndependency when you install Django with pip.
async_to_sync()Link to this heading#Wraps an asynchronous function and returns a synchronous function in its place.\nCan be used as either a direct wrapper or a decorator:
\nfrom asgiref.sync import async_to_sync\n\nsync_function = async_to_sync(async_function)\n\n@async_to_sync\nasync def async_function(...):\n ...\nThe asynchronous function is run in the event loop for the current thread, if\none is present. If there is no current event loop, a new event loop is spun up\nspecifically for the async function and shut down again once it completes. In\neither situation, the async function will execute on a different thread to the\ncalling code.
\nThreadlocals and contextvars values are preserved across the boundary in both\ndirections.
\nasync_to_sync() is essentially a more powerful version of the\nasyncio.run() function available in Python's standard library. As well\nas ensuring threadlocals work, it also enables the thread_sensitive mode of\nsync_to_async() when that wrapper is used below it.
sync_to_async()Link to this heading#Wraps a synchronous function and returns an asynchronous (awaitable) function\nin its place. Can be used as either a direct wrapper or a decorator:
\nfrom asgiref.sync import sync_to_async\n\nasync_function = sync_to_async(sync_function)\nasync_function = sync_to_async(sensitive_sync_function, thread_sensitive=True)\n\n@sync_to_async\ndef sync_function(...):\n ...\nThreadlocals and contextvars values are preserved across the boundary in both\ndirections.
\nSynchronous functions tend to be written assuming they all run in the main\nthread, so sync_to_async() has two threading modes:
thread_sensitive=False (the default): the synchronous function will run\nin a brand new thread which is then closed once it completes.
thread_sensitive=True: the synchronous function will run in the same\nthread as all other thread_sensitive functions, and this will be the main\nthread, if the main thread is synchronous and you are using the\nasync_to_sync() wrapper.
Thread-sensitive mode is quite special, and does a lot of work to run all\nfunctions in the same thread. Note, though, that it relies on usage of\nasync_to_sync() above it in the stack to correctly run things on the\nmain thread. If you use asyncio.run() (or other options instead), it will\nfall back to just running thread-sensitive functions in a single, shared thread\n(but not the main thread).
The reason this is needed in Django is that many libraries, specifically\ndatabase adapters, require that they are accessed in the same thread that they\nwere created in, and a lot of existing Django code assumes it all runs in the\nsame thread (e.g. middleware adding things to a request for later use by a\nview).
\nRather than introduce potential compatibility issues with this code, we instead\nopted to add this mode so that all existing Django synchronous code runs in the\nsame thread and thus is fully compatible with asynchronous mode. Note, that\nsynchronous code will always be in a different thread to any async code that\nis calling it, so you should avoid passing raw database handles or other\nthread-sensitive references around in any new code you write.
\n