]> git.ipfire.org Git - thirdparty/sqlalchemy/alembic.git/commitdiff
- 1.8.1 rel_1_8_1
authorMike Bayer <mike_mp@zzzcomputing.com>
Wed, 13 Jul 2022 14:17:20 +0000 (10:17 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Wed, 13 Jul 2022 14:17:20 +0000 (10:17 -0400)
docs/build/changelog.rst
docs/build/conf.py
docs/build/unreleased/1021.rst [deleted file]
docs/build/unreleased/1065.rst [deleted file]

index 9d43e0c8a16436f5ec96f3c37f68ea5752e895ce..cac0c61994cccb9d98231b91c67d736802fa56ac 100644 (file)
@@ -5,7 +5,33 @@ Changelog
 
 .. changelog::
     :version: 1.8.1
-    :include_notes_from: unreleased
+    :released: July 13, 2022
+
+    .. change::
+        :tags: bug, sqlite
+        :tickets: 1065
+
+        Fixed bug where the SQLite implementation of
+        :meth:`.Operations.rename_table` would render an explicit schema name for
+        both the old and new table name, which while is the standard ALTER syntax,
+        is not accepted by SQLite's syntax which doesn't support a rename across
+        schemas. In particular, the syntax issue would prevent batch mode from
+        working for SQLite databases that made use of attached databases (which are
+        treated as "schemas" in SQLAlchemy).
+
+    .. change::
+        :tags: bug, batch
+        :tickets: 1021
+
+        Added an error raise for the condition where
+        :meth:`.Operations.batch_alter_table` is used in ``--sql`` mode, where the
+        operation requires table reflection, as is the case when running against
+        SQLite without giving it a fixed ``Table`` object. Previously the operation
+        would fail with an internal error.   To get a "move and copy" batch
+        operation as a SQL script without connecting to a database,
+        a ``Table`` object should be passed to the
+        :paramref:`.Operations.batch_alter_table.copy_from` parameter so that
+        reflection may be skipped.
 
 .. changelog::
     :version: 1.8.0
index 940610b755fd2025927bd2520e5dc57f40ca8987..ba76b825e626515769f391fd88ec66e0b6ebdec9 100644 (file)
@@ -95,8 +95,8 @@ copyright = "2010-2022, Mike Bayer"  # noqa
 # The short X.Y version.
 version = alembic.__version__
 # The full version, including alpha/beta/rc tags.
-release = "1.8.0"
-release_date = "May 31, 2022"
+release = "1.8.1"
+release_date = "July 13, 2022"
 
 
 # The language for content autogenerated by Sphinx. Refer to documentation
diff --git a/docs/build/unreleased/1021.rst b/docs/build/unreleased/1021.rst
deleted file mode 100644 (file)
index 3d9752c..0000000
+++ /dev/null
@@ -1,13 +0,0 @@
-.. change::
-    :tags: bug, batch
-    :tickets: 1021
-
-    Added an error raise for the condition where
-    :meth:`.Operations.batch_alter_table` is used in ``--sql`` mode, where the
-    operation requires table reflection, as is the case when running against
-    SQLite without giving it a fixed ``Table`` object. Previously the operation
-    would fail with an internal error.   To get a "move and copy" batch
-    operation as a SQL script without connecting to a database,
-    a ``Table`` object should be passed to the
-    :paramref:`.Operations.batch_alter_table.copy_from` parameter so that
-    reflection may be skipped.
\ No newline at end of file
diff --git a/docs/build/unreleased/1065.rst b/docs/build/unreleased/1065.rst
deleted file mode 100644 (file)
index 42a97a6..0000000
+++ /dev/null
@@ -1,11 +0,0 @@
-.. change::
-    :tags: bug, sqlite
-    :tickets: 1065
-
-    Fixed bug where the SQLite implementation of
-    :meth:`.Operations.rename_table` would render an explicit schema name for
-    both the old and new table name, which while is the standard ALTER syntax,
-    is not accepted by SQLite's syntax which doesn't support a rename across
-    schemas. In particular, the syntax issue would prevent batch mode from
-    working for SQLite databases that made use of attached databases (which are
-    treated as "schemas" in SQLAlchemy).