From: Mike Bayer Date: Thu, 6 Aug 2020 14:16:38 +0000 (-0400) Subject: revise asyncio verbiage a bit X-Git-Tag: rel_1_4_0b1~193 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f1626c784efc800a912a815085b9bac609c0d1cb;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git revise asyncio verbiage a bit Change-Id: I8bdf7c3271b8284ab82e01558024f933e1ee7b49 --- diff --git a/doc/build/changelog/migration_20.rst b/doc/build/changelog/migration_20.rst index d6077462e2..535756f53e 100644 --- a/doc/build/changelog/migration_20.rst +++ b/doc/build/changelog/migration_20.rst @@ -1257,15 +1257,15 @@ Asyncio Support path to having lazy loading be available, for those willing to make use of some "controversial" patterns. -There was an entire section here detailing how asyncio is a nice to have, -but not really necessary, there are some approaches already, and maybe -third parties can keep doing it. +There was previously an entire section here detailing how asyncio is a nice to +have, but not really necessary from a technical standpoint, there are some +approaches already, and maybe third parties can keep doing it. What's changed is that there is now an approach to doing this in SQLAlchemy -directly that does not impact the existing library nor does it imply an -entirely separate version of everything be maintained. What has *not* changed -is that asyncio is not very necessary for relational databases but **that's -fine, we will have asyncio, no more need to debate :) :) :)**. +directly that does not impact the existing library internals nor does it imply +an entirely separate version of everything be maintained, therefore this makes +it feasible to deliver this feature to those users who prefer an all-async +application style without impact on the traditional blocking archictecture. The proof of concept at https://gist.github.com/zzzeek/4e89ce6226826e7a8df13e1b573ad354 illustrates how to write an asyncio application that makes use of a pure asyncio @@ -1372,7 +1372,8 @@ from inside of an ``asyncio.run()`` call rather than directly, and it uses a DBAPI that is only compatible with asyncio. There is no "monkeypatching" or anything else like that involved. Any asyncio program can opt to place it's database-related business methods into the above pattern, -if preferred, rather than using the asyncio SQLAlchemy API directly. Or not. -The greenlet technique, which is also being ported to other frameworks -suich as Flask, has now made it so that it **no longer matters**. +if preferred, rather than using the asyncio SQLAlchemy API directly. This +technique is also being adapted to other frameworks such as Flask and will +hopefully lead to greater interoperability between blocking and non-blocking +libraries and frameworks.