From: Mike Bayer Date: Wed, 5 Apr 2023 23:28:29 +0000 (-0400) Subject: - 2.0.9 X-Git-Tag: rel_2_0_9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0d9221362e5a3e50de7e21e674da3701f4bcd646;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git - 2.0.9 --- diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst index efa00b943a..20c64353b8 100644 --- a/doc/build/changelog/changelog_20.rst +++ b/doc/build/changelog/changelog_20.rst @@ -10,7 +10,49 @@ .. changelog:: :version: 2.0.9 - :include_notes_from: unreleased_20 + :released: April 5, 2023 + + .. change:: + :tags: bug, mssql + :tickets: 9603 + + Due to a critical bug identified in SQL Server, the SQLAlchemy + "insertmanyvalues" feature which allows fast INSERT of many rows while also + supporting RETURNING unfortunately needs to be disabled for SQL Server. SQL + Server is apparently unable to guarantee that the order of rows inserted + matches the order in which they are sent back by OUTPUT inserted when + table-valued rows are used with INSERT in conjunction with OUTPUT inserted. + We are trying to see if Microsoft is able to confirm this undocumented + behavior however there is no known workaround, other than it's not safe to + use table-valued expressions with OUTPUT inserted for now. + + + .. change:: + :tags: bug, mariadb + :tickets: 9588 + + Added ``row_number`` as reserved word in MariaDb. + + .. change:: + :tags: bug, mssql + :tickets: 9586 + + Changed the bulk INSERT strategy used for SQL Server "executemany" with + pyodbc when ``fast_executemany`` is set to ``True`` by using + ``fast_executemany`` / ``cursor.executemany()`` for bulk INSERT that does + not include RETURNING, restoring the same behavior as was used in + SQLAlchemy 1.4 when this parameter is set. + + New performance details from end users have shown that ``fast_executemany`` + is still much faster for very large datasets as it uses ODBC commands that + can receive all rows in a single round trip, allowing for much larger + datasizes than the batches that can be sent by "insertmanyvalues" + as was implemented for SQL Server. + + While this change was made such that "insertmanyvalues" continued to be + used for INSERT that includes RETURNING, as well as if ``fast_executemany`` + were not set, due to :ticket:`9603`, the "insertmanyvalues" strategy has + been disabled for SQL Server across the board in any case. .. changelog:: :version: 2.0.8 diff --git a/doc/build/changelog/unreleased_20/9586.rst b/doc/build/changelog/unreleased_20/9586.rst deleted file mode 100644 index 4dce60d638..0000000000 --- a/doc/build/changelog/unreleased_20/9586.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. change:: - :tags: bug, mssql - :tickets: 9586 - - Changed the bulk INSERT strategy used for SQL Server "executemany" with - pyodbc when ``fast_executemany`` is set to ``True`` by using - ``fast_executemany`` / ``cursor.executemany()`` for bulk INSERT that does - not include RETURNING, restoring the same behavior as was used in - SQLAlchemy 1.4 when this parameter is set. - - New performance details from end users have shown that ``fast_executemany`` - is still much faster for very large datasets as it uses ODBC commands that - can receive all rows in a single round trip, allowing for much larger - datasizes than the batches that can be sent by "insertmanyvalues" - as was implemented for SQL Server. - - While this change was made such that "insertmanyvalues" continued to be - used for INSERT that includes RETURNING, as well as if ``fast_executemany`` - were not set, due to :ticket:`9603`, the "insertmanyvalues" strategy has - been disabled for SQL Server across the board in any case. diff --git a/doc/build/changelog/unreleased_20/9588.rst b/doc/build/changelog/unreleased_20/9588.rst deleted file mode 100644 index 716a0a93a9..0000000000 --- a/doc/build/changelog/unreleased_20/9588.rst +++ /dev/null @@ -1,5 +0,0 @@ -.. change:: - :tags: bug, mariadb - :tickets: 9588 - - Added ``row_number`` as reserved word in MariaDb. diff --git a/doc/build/changelog/unreleased_20/9603.rst b/doc/build/changelog/unreleased_20/9603.rst deleted file mode 100644 index 0af82ae1f1..0000000000 --- a/doc/build/changelog/unreleased_20/9603.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. change:: - :tags: bug, mssql - :tickets: 9603 - - Due to a critical bug identified in SQL Server, the SQLAlchemy - "insertmanyvalues" feature which allows fast INSERT of many rows while also - supporting RETURNING unfortunately needs to be disabled for SQL Server. SQL - Server is apparently unable to guarantee that the order of rows inserted - matches the order in which they are sent back by OUTPUT inserted when - table-valued rows are used with INSERT in conjunction with OUTPUT inserted. - We are trying to see if Microsoft is able to confirm this undocumented - behavior however there is no known workaround, other than it's not safe to - use table-valued expressions with OUTPUT inserted for now. - diff --git a/doc/build/conf.py b/doc/build/conf.py index 955cbb6563..531c5df235 100644 --- a/doc/build/conf.py +++ b/doc/build/conf.py @@ -242,9 +242,9 @@ copyright = "2007-2023, the SQLAlchemy authors and contributors" # noqa # The short X.Y version. version = "2.0" # The full version, including alpha/beta/rc tags. -release = "2.0.8" +release = "2.0.9" -release_date = "March 31, 2023" +release_date = "April 5, 2023" site_base = os.environ.get("RTD_SITE_BASE", "https://www.sqlalchemy.org") site_adapter_template = "docs_adapter.mako"