Re: [cx-oracle-users] async
Brought to you by:
atuining
From: Andrew Z <fo...@gm...> - 2017-10-26 14:05:13
|
Norman, True. That is exactly how i use it. If you think about it, the "executer" is for those routines that can not be execited in the same thread ( blocking ). In the sense, running part of a program using asyncio single thread model and then spawning tons of threads for DB, is inconsistent from architectural perspective. We may ask - why bother with asyncio, if i have to use threads for a db. Or even, use other "asyncio compatible " driver + db - postgres, mysql, mongo those drivers are "asyncio ready" - https://aiopg.readthedocs.io/en/stable/ http://motor.readthedocs.io/en/stable/tutorial-asyncio.html https://github.com/aio-libs/aiomysql I also found these articles/discussions useful presenting different view points: http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ https://groups.google.com/forum/m/#!topic/zodb/ON3Q3E8HWtM https://news.ycombinator.com/item?id=9053286 On Oct 26, 2017 06:39, "Norman Denayer" <den...@gm...> wrote: Hello Walter, (We can use cx_Oracle with these frameworks now, but during any calls to the database the code can do nothing else except wait for the answer from the database). Actually, cx_Oracle use the macros Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS to let other threads run during driver calls and database work. So even without an async version of cx_Oracle, you may execute your calls in a “*concurrent.futures.ThreadPoolExecutor*” Of course it’s not perfect but it allows async code still call non-async code in a non-blocking way. See: https://docs.python.org/3/library/asyncio-eventloop.html#executor https://docs.python.org/3/library/concurrent.futures. html#concurrent.futures.ThreadPoolExecutor Norman On 26 Oct 2017, at 10:47, Walter Dörwald <wa...@li...> wrote: On 24 Oct 2017, at 19:57, Anthony Tuininga wrote: Hi Andrew, Apologies for the delay in response. I had a busy month. :-) There are no current plans to make cx_Oracle "compatible" with asyncio, but that could change -- especially if you provided some indication of what you meant by that request! It might be useful to create an issue on the cx_Oracle issues page providing some more details. That will give others a chance to comment a well, since not everyone is on the mailing list. I guess this would mean that for each method that talks to the database there should be an async version, i.e. instead of def print_foo(): cursor.execute("select * from foo") for row in cursor: print(row) we could do: async def print_foo(): await cursor.execute("select * from foo") async for row in cursor: print(row) Then we could use cx_Oracle with other async frameworks (aiohttp, sanic and probably Tornado and Twisted and a bunch others) and take advantage of cx_Oracle's new async features. (We can use cx_Oracle with these frameworks now, but during any calls to the database the code can do nothing else except wait for the answer from the database). Details for async/await are in PEP 492 at https://www.python.org/dev/ peps/pep-0492/ Anthony On Mon, Sep 25, 2017 at 10:22 PM, Andrew Zyman <fo...@gm...> wrote: Hello, wonder if there are any plans to make the module "compatible" with asyncio ? Thank you AZ Servus, Walter ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ cx-oracle-users mailing list cx-...@li... https://lists.sourceforge.net/lists/listinfo/cx-oracle-users ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ cx-oracle-users mailing list cx-...@li... https://lists.sourceforge.net/lists/listinfo/cx-oracle-users |