Thanks for your lightning fast reply! Actually my interest in asyncio is guided pretty much because I'm using autobahn to do non-blocking websocket stuffs and and since it uses asyncio I thought it would be seamless if I could use it to handle DB non-blocking operations too.
I'll take a look at your blog post for a matter of clarification and try to figure something out. Probably I'll show up here again soon. Thanks On Wed, Sep 16, 2015 at 11:37 AM, Mike Bayer <mike...@zzzcomputing.com> wrote: > > > On 9/16/15 10:17 AM, Johnny W. Santos wrote: > > Hi guys, > > I would like to know if theres is any chances to SQLAlchemy support > asyncio out of the box? Like the ORM and such. > > > Well the "real" answer is "yes", which is that you'd put your ORM business > logic in a threadpool using > https://docs.python.org/3/library/asyncio-eventloop.html#executor. This > will by far get you the best separation of asyncio's ORM-unfriendly > concepts, the superior performance of traditional threads for that work, > and the programming patterns that some people find important in asyncio on > the outside of the traditional ORM-centric code. For rationale on this > as well as proof that asyncio's slowness and database awkwardness is > entirely not worth it nor even appropriate, see > http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/. > > As far as an asyncio-explicit API for SQLAlchemy ORM, ORMs can't work very > well with asyncio because they rely upon "lazy loading", which is a > programming pattern directly in opposition to the philosophies of asyncio. > That said, the Core can be made to work in an asyncio fashion but there's > no roadmap for doing this extremely large amount of work (issue is at > https://bitbucket.org/zzzeek/sqlalchemy/issues/3414/asyncio-and-sqlalchemy). > > > There's also a project that re-implements very partial versions of parts > of the Core to work on top of asynchronous psycopg2, that is > https://github.com/aio-libs/aiopg. Note however this project > re-implements the execution internals completely so basic features like > column defaults and datatypes won't really work as designed. > > IMO there *is* a technically appropriate and performant solution to your > problem but it would require that you release any dogmatism you might have > over the use of traditional threaded code within the context of explicit > async code. > > > Thanks > > Johnny > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > -- Johnny W. dos Santos -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
