From a968c9d2832173ee7d5dde50c7573f7b99424c38 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Wed, 13 Jul 2022 10:17:20 -0400 Subject: [PATCH] - 1.8.1 --- docs/build/changelog.rst | 28 +++++++++++++++++++++++++++- docs/build/conf.py | 4 ++-- docs/build/unreleased/1021.rst | 13 ------------- docs/build/unreleased/1065.rst | 11 ----------- 4 files changed, 29 insertions(+), 27 deletions(-) delete mode 100644 docs/build/unreleased/1021.rst delete mode 100644 docs/build/unreleased/1065.rst diff --git a/docs/build/changelog.rst b/docs/build/changelog.rst index 9d43e0c8..cac0c619 100644 --- a/docs/build/changelog.rst +++ b/docs/build/changelog.rst @@ -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 diff --git a/docs/build/conf.py b/docs/build/conf.py index 940610b7..ba76b825 100644 --- a/docs/build/conf.py +++ b/docs/build/conf.py @@ -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 index 3d9752c4..00000000 --- a/docs/build/unreleased/1021.rst +++ /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 index 42a97a60..00000000 --- a/docs/build/unreleased/1065.rst +++ /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). -- 2.47.2