]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commitdiff
- 2.0.9 rel_2_0_9
authorMike Bayer <mike_mp@zzzcomputing.com>
Wed, 5 Apr 2023 23:28:29 +0000 (19:28 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Wed, 5 Apr 2023 23:28:29 +0000 (19:28 -0400)
doc/build/changelog/changelog_20.rst
doc/build/changelog/unreleased_20/9586.rst [deleted file]
doc/build/changelog/unreleased_20/9588.rst [deleted file]
doc/build/changelog/unreleased_20/9603.rst [deleted file]
doc/build/conf.py

index efa00b943ae2d95a471bffad51f4c36e8603bcf1..20c64353b8534f1b58df8cbd38b2aa0431b2529c 100644 (file)
 
 .. 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 (file)
index 4dce60d..0000000
+++ /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 (file)
index 716a0a9..0000000
+++ /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 (file)
index 0af82ae..0000000
+++ /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.
-
index 955cbb65638f9c60ac684519f47928c770148083..531c5df2359bf4e94e291110a10b5cc7698a3116 100644 (file)
@@ -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"