- 1.4.22

2026-05-16 21:57:22 -04:00 · 2021-07-21 18:53:27 -04:00
parent 8822d83267
commit 044d951ea4
9 changed files with 84 additions and 77 deletions
@@ -15,7 +15,88 @@ This document details individual issue-level changes made throughout

 .. changelog::
    :version: 1.4.22
-    :include_notes_from: unreleased_14
+    :released: July 21, 2021
+
+    .. change::
+        :tags: bug, sql
+        :tickets: 6786
+
+        Fixed issue where use of the :paramref:`_sql.case.whens` parameter passing
+        a dictionary positionally and not as a keyword argument would emit a 2.0
+        deprecation warning, referring to the deprecation of passing a list
+        positionally. The dictionary format of "whens", passed positionally, is
+        still supported and was accidentally marked as deprecated.
+
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6775
+
+        Fixed issue in new :meth:`_schema.Table.table_valued` method where the
+        resulting :class:`_sql.TableValuedColumn` construct would not respond
+        correctly to alias adaptation as is used throughout the ORM, such as for
+        eager loading, polymorphic loading, etc.
+
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6769
+
+        Fixed issue where usage of the :meth:`_result.Result.unique` method with an
+        ORM result that included column expressions with unhashable types, such as
+        ``JSON`` or ``ARRAY`` using non-tuples would silently fall back to using
+        the ``id()`` function, rather than raising an error. This now raises an
+        error when the :meth:`_result.Result.unique` method is used in a 2.0 style
+        ORM query. Additionally, hashability is assumed to be True for result
+        values of unknown type, such as often happens when using SQL functions of
+        unknown return type; if values are truly not hashable then the ``hash()``
+        itself will raise.
+
+        For legacy ORM queries, since the legacy :class:`_orm.Query` object
+        uniquifies in all cases, the old rules remain in place, which is to use
+        ``id()`` for result values of unknown type as this legacy uniquing is
+        mostly for the purpose of uniquing ORM entities and not column values.
+
+    .. change::
+        :tags: orm, bug
+        :tickets: 6771
+
+        Fixed an issue where clearing of mappers during things like test suite
+        teardowns could cause a "dictionary changed size" warning during garbage
+        collection, due to iteration of a weak-referencing dictionary. A ``list()``
+        has been applied to prevent concurrent GC from affecting this operation.
+
+    .. change::
+        :tags: bug, sql
+        :tickets: 6770
+
+        Fixed issue where type-specific bound parameter handlers would not be
+        called upon in the case of using the :meth:`_sql.Insert.values` method with
+        the Python ``None`` value; in particular, this would be noticed when using
+        the :class:`_types.JSON` datatype as well as related PostgreSQL specific
+        types such as :class:`_postgresql.JSONB` which would fail to encode the
+        Python ``None`` value into JSON null, however the issue was generalized to
+        any bound parameter handler in conjunction with this specific method of
+        :class:`_sql.Insert`.
+
+
+    .. change::
+        :tags: bug, engine
+        :tickets: 6740
+
+        Added some guards against ``KeyError`` in the event system to accommodate
+        the case that the interpreter is shutting down at the same time
+        :meth:`_engine.Engine.dispose` is being called, which would cause stack
+        trace warnings.
+
+
+    .. change::
+        :tags: bug, orm, regression
+        :tickets: 6793
+
+        Fixed critical caching issue where the ORM's persistence feature using
+        INSERT..RETURNING would cache an incorrect query when mixing the "bulk
+        save" and standard "flush" forms of INSERT.

 .. changelog::
    :version: 1.4.21
@@ -1,9 +0,0 @@
-.. change::
-    :tags: bug, engine
-    :tickets: 6740
-
-    Added some guards against ``KeyError`` in the event system to accommodate
-    the case that the interpreter is shutting down at the same time
-    :meth:`_engine.Engine.dispose` is being called, which would cause stack
-    trace warnings.
-
@@ -1,18 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 6769
-
-    Fixed issue where usage of the :meth:`_result.Result.unique` method with an
-    ORM result that included column expressions with unhashable types, such as
-    ``JSON`` or ``ARRAY`` using non-tuples would silently fall back to using
-    the ``id()`` function, rather than raising an error. This now raises an
-    error when the :meth:`_result.Result.unique` method is used in a 2.0 style
-    ORM query. Additionally, hashability is assumed to be True for result
-    values of unknown type, such as often happens when using SQL functions of
-    unknown return type; if values are truly not hashable then the ``hash()``
-    itself will raise.
-
-    For legacy ORM queries, since the legacy :class:`_orm.Query` object
-    uniquifies in all cases, the old rules remain in place, which is to use
-    ``id()`` for result values of unknown type as this legacy uniquing is
-    mostly for the purpose of uniquing ORM entities and not column values.
@@ -1,13 +0,0 @@
-.. change::
-    :tags: bug, sql
-    :tickets: 6770
-
-    Fixed issue where type-specific bound parameter handlers would not be
-    called upon in the case of using the :meth:`_sql.Insert.values` method with
-    the Python ``None`` value; in particular, this would be noticed when using
-    the :class:`_types.JSON` datatype as well as related PostgreSQL specific
-    types such as :class:`_postgresql.JSONB` which would fail to encode the
-    Python ``None`` value into JSON null, however the issue was generalized to
-    any bound parameter handler in conjunction with this specific method of
-    :class:`_sql.Insert`.
-
@@ -1,8 +0,0 @@
-.. change::
-    :tags: orm, bug
-    :tickets: 6771
-
-    Fixed an issue where clearing of mappers during things like test suite
-    teardowns could cause a "dictionary changed size" warning during garbage
-    collection, due to iteration of a weak-referencing dictionary. A ``list()``
-    has been applied to prevent concurrent GC from affecting this operation.
@@ -1,9 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 6775
-
-    Fixed issue in new :meth:`_schema.Table.table_valued` method where the
-    resulting :class:`_sql.TableValuedColumn` construct would not respond
-    correctly to alias adaptation as is used throughout the ORM, such as for
-    eager loading, polymorphic loading, etc.
-
@@ -1,10 +0,0 @@
-.. change::
-    :tags: bug, sql
-    :tickets: 6786
-
-    Fixed issue where use of the :paramref:`_sql.case.whens` parameter passing
-    a dictionary positionally and not as a keyword argument would emit a 2.0
-    deprecation warning, referring to the deprecation of passing a list
-    positionally. The dictionary format of "whens", passed positionally, is
-    still supported and was accidentally marked as deprecated.
-
@@ -1,7 +0,0 @@
-.. change::
-    :tags: bug, orm, regression
-    :tickets: 6793
-
-    Fixed critical caching issue where the ORM's persistence feature using
-    INSERT..RETURNING would cache an incorrect query when mixing the "bulk
-    save" and standard "flush" forms of INSERT.
@@ -196,9 +196,9 @@ copyright = u"2007-2021, the SQLAlchemy authors and contributors"  # noqa
 # The short X.Y version.
 version = "1.4"
 # The full version, including alpha/beta/rc tags.
-release = "1.4.21"
+release = "1.4.22"

-release_date = "July 14, 2021"
+release_date = "July 21, 2021"

 site_base = os.environ.get("RTD_SITE_BASE", "https://www.sqlalchemy.org")
 site_adapter_template = "docs_adapter.mako"