pony
pony copied to clipboard
ponyorm
asyncio + futures support
With new async web frameworks such as Sanic, I would love to be able to use this library with the new async/await syntax.
+1
It would be great to also support trio (an alternative event loop implementation on top of async/await with a much nicer API)
https://docs.ponyorm.com/transactions.html#using-db-session-with-generator-functions-or-coroutines is that not enough for now ?
Ok, so changes that native async needs:
- Do not perform blocking IO. That means that you need a new set of database libraries (eg asyncpg).
- The asyncness of functions that do IO has to trickle up. So compiling SQL is a CPU-bound task and can still be done the same way. But the functions that send those queries to the database library have to be async, and the functions that glue together the user-facing APIs with the query compiler and the query executors become async, and then the actual public APIs become async.
Honestly, the simpler way is to use the integration of asyncio and concurrent.futures to make async proxies that send the work to a background thread, rather than trying to retool an entire library to be async. Preferably with a heavy dose of metaprogramming.
And no, I don't know of any tools that will allow a single source to act as both sync and async. In theory, you could strip all the async-related keywords, but you still need a way to interact with the libraries you talk to (either by switching libraries or wrapping in a sync-async bridge).
Trust me, I've been down this road, I have my own library that attempts to live in both worlds. It's not great.
@astronouth7303 telethon is using own synchronizer for async API to be able to be used as sync lib You should take a look ;)
When Pony does not perform blocking IO and start use async/await, will lazy fetch still be usable?
I mean, before thinking modifying Pony. Lazy fetch does conflict with async/await. How can this problem be solved?
Ok, so changes that native async needs:
- Do not perform blocking IO. That means that you need a new set of database libraries (eg asyncpg).
- The asyncness of functions that do IO has to trickle up. So compiling SQL is a CPU-bound task and can still be done the same way. But the functions that send those queries to the database library have to be async, and the functions that glue together the user-facing APIs with the query compiler and the query executors become async, and then the actual public APIs become async.
Honestly, the simpler way is to use the integration of asyncio and concurrent.futures to make async proxies that send the work to a background thread, rather than trying to retool an entire library to be async. Preferably with a heavy dose of metaprogramming.
And no, I don't know of any tools that will allow a single source to act as both sync and async. In theory, you could strip all the async-related keywords, but you still need a way to interact with the libraries you talk to (either by switching libraries or wrapping in a sync-async bridge).
Trust me, I've been down this road, I have my own library that attempts to live in both worlds. It's not great.
I'm wondering since the most awesome part of Pony is the SQL query builder if this could be used standalone, so it the resulting queries could be used with an async client? Or someone could build an async Pony by importing the query builder but rebuilding with async in mind?
I'm wondering since the most awesome part of Pony is the SQL query builder if this could be used standalone, so it the resulting queries could be used with an async client? Or someone could build an async Pony by importing the query builder but rebuilding with async in mind?
maybe a pure Pony SQL query builder is a key for aio pony
