- 1.4.23rel_1_4_23

18 files changed, 228 insertions, 212 deletions

diff --git a/doc/build/changelog/changelog_14.rst b/doc/build/changelog/changelog_14.rst
index 72e4a2d22..8426e6de8 100644
--- a/doc/build/changelog/changelog_14.rst
+++ b/doc/build/changelog/changelog_14.rst
@@ -15,7 +15,232 @@ This document details individual issue-level changes made throughout
 
 .. changelog::
     :version: 1.4.23
-    :include_notes_from: unreleased_14
+    :released: August 18, 2021
+
+    .. change::
+        :tags: bug, sql
+        :tickets: 6752
+
+        Fix issue in :class:`_sql.CTE` where new :meth:`_sql.HasCTE.add_cte` method
+        added in version 1.4.21 / :ticket:`6752` failed to function correctly for
+        "compound select" structures such as :func:`_sql.union`,
+        :func:`_sql.union_all`, :func:`_sql.except`, etc. Pull request courtesy
+        Eric Masseran.
+
+    .. change::
+        :tags: orm, usecase
+        :tickets: 6808
+
+        Added new attribute :attr:`_sql.Select.columns_clause_froms` that will
+        retrieve the FROM list implied by the columns clause of the
+        :class:`_sql.Select` statement. This differs from the old
+        :attr:`_sql.Select.froms` collection in that it does not perform any ORM
+        compilation steps, which necessarily deannotate the FROM elements and do
+        things like compute joinedloads etc., which makes it not an appropriate
+        candidate for the :meth:`_sql.Select.select_from` method. Additionally adds
+        a new parameter
+        :paramref:`_sql.Select.with_only_columns.maintain_column_froms` that
+        transfers this collection to :meth:`_sql.Select.select_from` before
+        replacing the columns collection.
+
+        In addition, the :attr:`_sql.Select.froms` is renamed to
+        :meth:`_sql.Select.get_final_froms`, to stress that this collection is not
+        a simple accessor and is instead calculated given the full state of the
+        object, which can be an expensive call when used in an ORM context.
+
+        Additionally fixes a regression involving the
+        :func:`_orm.with_only_columns` function to support applying criteria to
+        column elements that were replaced with either
+        :meth:`_sql.Select.with_only_columns` or :meth:`_orm.Query.with_entities` ,
+        which had broken as part of :ticket:`6503` released in 1.4.19.
+
+    .. change::
+        :tags: bug, orm, sql
+        :tickets: 6824
+
+        Fixed issue where a bound parameter object that was "cloned" would cause a
+        name conflict in the compiler, if more than one clone of this parameter
+        were used at the same time in a single statement. This could occur in
+        particular with things like ORM single table inheritance queries that
+        indicated the same "discriminator" value multiple times in one query.
+
+
+    .. change::
+        :tags: bug, mssql, sql
+        :tickets: 6863
+
+        Fixed issue where the ``literal_binds`` compiler flag, as used externally
+        to render bound parameters inline, would fail to work when used with a
+        certain class of parameters known as "literal_execute", which covers things
+        like LIMIT and OFFSET values for dialects where the drivers don't allow a
+        bound parameter, such as SQL Server's "TOP" clause.  The issue locally
+        seemed to affect only the MSSQL dialect.
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6869
+
+        Fixed issue in loader strategies where the use of the
+        :meth:`_orm.Load.options` method, particularly when nesting multiple calls,
+        would generate an overly long and more importantly non-deterministic cache
+        key, leading to very large cache keys which were also not allowing
+        efficient cache usage, both in terms of total memory used as well as number
+        of entries used in the cache itself.
+
+    .. change::
+        :tags: bug, sql
+        :tickets: 6858
+
+        Fixed an issue in the ``CacheKey.to_offline_string()`` method used by the
+        dogpile.caching example where attempting to create a proper cache key from
+        the special "lambda" query generated by the lazy loader would fail to
+        include the parameter values, leading to an incorrect cache key.
+
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6887
+
+        Revised the means by which the
+        :attr:`_orm.ORMExecuteState.user_defined_options` accessor receives
+        :class:`_orm.UserDefinedOption` and related option objects from the
+        context, with particular emphasis on the "selectinload" on the loader
+        strategy where this previously was not working; other strategies did not
+        have this problem. The objects that are associated with the current query
+        being executed, and not that of a query being cached, are now propagated
+        unconditionally. This essentially separates them out from the "loader
+        strategy" options which are explicitly associated with the compiled state
+        of a query and need to be used in relation to the cached query.
+
+        The effect of this fix is that a user-defined option, such as those used
+        by the dogpile.caching example as well as for other recipes such as
+        defining a "shard id" for the horizontal sharing extension, will be
+        correctly propagated to eager and lazy loaders regardless of whether
+        a cached query was ultimately invoked.
+
+
+    .. change::
+        :tags: bug, sql
+        :tickets: 6886
+
+        Adjusted the "from linter" warning feature to accommodate for a chain of
+        joins more than one level deep where the ON clauses don't explicitly match
+        up the targets, such as an expression such as "ON TRUE". This mode of use
+        is intended to cancel the cartesian product warning simply by the fact that
+        there's a JOIN from "a to b", which was not working for the case where the
+        chain of joins had more than one element.
+
+    .. change::
+        :tags: bug, postgresql
+        :tickets: 6886
+
+        Added the "is_comparison" flag to the PostgreSQL "overlaps",
+        "contained_by", "contains" operators, so that they work in relevant ORM
+        contexts as well as in conjunction with the "from linter" feature.
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6812
+
+        Fixed issue where the unit of work would internally use a 2.0-deprecated
+        SQL expression form, emitting a deprecation warning when SQLALCHEMY_WARN_20
+        were enabled.
+
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6881
+
+        Fixed issue in :func:`_orm.selectinload` where use of the new
+        :meth:`_orm.PropComparator.and_` feature within options that were nested
+        more than one level deep would fail to update bound parameter values that
+        were in the nested criteria, as a side effect of SQL statement caching.
+
+
+    .. change::
+        :tags: bug, general
+        :tickets: 6136
+
+        The setup requirements have been modified such ``greenlet`` is a default
+        requirement only for those platforms that are well known for ``greenlet``
+        to be installable and for which there is already a pre-built binary on
+        pypi; the current list is ``x86_64 aarch64 ppc64le amd64 win32``. For other
+        platforms, greenlet will not install by default, which should enable
+        installation and test suite running of SQLAlchemy 1.4 on platforms that
+        don't support ``greenlet``, excluding any asyncio features. In order to
+        install with the ``greenlet`` dependency included on a machine architecture
+        outside of the above list, the ``[asyncio]`` extra may be included by
+        running ``pip install sqlalchemy[asyncio]`` which will then attempt to
+        install ``greenlet``.
+
+        Additionally, the test suite has been repaired so that tests can complete
+        fully when greenlet is not installed, with appropriate skips for
+        asyncio-related tests.
+
+    .. change::
+        :tags: enum, schema
+        :tickets: 6146
+
+        Unify behaviour :class:`_schema.Enum` in native and non-native
+        implementations regarding the accepted values for an enum with
+        aliased elements.
+        When :paramref:`_schema.Enum.omit_aliases` is ``False`` all values,
+        alias included, are accepted as valid values.
+        When :paramref:`_schema.Enum.omit_aliases` is ``True`` only non aliased values
+        are accepted as valid values.
+
+    .. change::
+        :tags: bug, ext
+        :tickets: 6816
+
+        Fixed issue where the horizontal sharding extension would not correctly
+        accommodate for a plain textual SQL statement passed to
+        :meth:`_orm.Session.execute`.
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6889, 6079
+
+        Adjusted ORM loader internals to no longer use the "lambda caching" system
+        that was added in 1.4, as well as repaired one location that was still
+        using the previous "baked query" system for a query. The lambda caching
+        system remains an effective way to reduce the overhead of building up
+        queries that have relatively fixed usage patterns. In the case of loader
+        strategies, the queries used are responsible for moving through lots of
+        arbitrary options and criteria, which is both generated and sometimes
+        consumed by end-user code, that make the lambda cache concept not any more
+        efficient than not using it, at the cost of more complexity. In particular
+        the problems noted by :ticket:`6881` and :ticket:`6887` are made are made
+        considerably less complicated by removing this feature internally.
+
+
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 6889
+
+        Fixed an issue where the :class:`_orm.Bundle` construct would not create
+        proper cache keys, leading to inefficient use of the query cache.  This
+        had some impact on the "selectinload" strategy and was identified as
+        part of :ticket:`6889`.
+
+    .. change::
+        :tags: usecase, mypy
+        :tickets: 6804, 6759
+
+        Added support for SQLAlchemy classes to be defined in user code using
+        "generic class" syntax as defined by ``sqlalchemy2-stubs``, e.g.
+        ``Column[String]``, without the need for qualifying these constructs within
+        a ``TYPE_CHECKING`` block by implementing the Python special method
+        ``__class_getitem__()``, which allows this syntax to pass without error at
+        runtime.
+
+    .. change::
+        :tags: bug, sql
+
+        Fixed issue in lambda caching system where an element of a query that
+        produces no cache key, like a custom option or clause element, would still
+        populate the expression in the "lambda cache" inappropriately.
 
 .. changelog::
     :version: 1.4.22
diff --git a/doc/build/changelog/unreleased_14/6136.rst b/doc/build/changelog/unreleased_14/6136.rst
deleted file mode 100644
index de3b2feb1..000000000
--- a/doc/build/changelog/unreleased_14/6136.rst
+++ /dev/null
@@ -1,19 +0,0 @@
-.. change::
-    :tags: bug, general
-    :tickets: 6136
-
-    The setup requirements have been modified such ``greenlet`` is a default
-    requirement only for those platforms that are well known for ``greenlet``
-    to be installable and for which there is already a pre-built binary on
-    pypi; the current list is ``x86_64 aarch64 ppc64le amd64 win32``. For other
-    platforms, greenlet will not install by default, which should enable
-    installation and test suite running of SQLAlchemy 1.4 on platforms that
-    don't support ``greenlet``, excluding any asyncio features. In order to
-    install with the ``greenlet`` dependency included on a machine architecture
-    outside of the above list, the ``[asyncio]`` extra may be included by
-    running ``pip install sqlalchemy[asyncio]`` which will then attempt to
-    install ``greenlet``.
-
-    Additionally, the test suite has been repaired so that tests can complete
-    fully when greenlet is not installed, with appropriate skips for
-    asyncio-related tests.
\ No newline at end of file
diff --git a/doc/build/changelog/unreleased_14/6146.rst b/doc/build/changelog/unreleased_14/6146.rst
deleted file mode 100644
index 418fbc4e2..000000000
--- a/doc/build/changelog/unreleased_14/6146.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. change::
-    :tags: enum, schema
-    :tickets: 6146
-
-    Unify behaviour :class:`_schema.Enum` in native and non-native
-    implementations regarding the accepted values for an enum with
-    aliased elements.
-    When :paramref:`_schema.Enum.omit_aliases` is ``False`` all values,
-    alias included, are accepted as valid values.
-    When :paramref:`_schema.Enum.omit_aliases` is ``True`` only non aliased values
-    are accepted as valid values.
diff --git a/doc/build/changelog/unreleased_14/6752.rst b/doc/build/changelog/unreleased_14/6752.rst
deleted file mode 100644
index 9cc07c2a1..000000000
--- a/doc/build/changelog/unreleased_14/6752.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. change::
-    :tags: bug, sql
-    :tickets: 6752
-
-    Fix issue in :class:`_sql.CTE` where new :meth:`_sql.HasCTE.add_cte` method
-    added in version 1.4.21 / :ticket:`6752` failed to function correctly for
-    "compound select" structures such as :func:`_sql.union`,
-    :func:`_sql.union_all`, :func:`_sql.except`, etc. Pull request courtesy
-    Eric Masseran.
\ No newline at end of file
diff --git a/doc/build/changelog/unreleased_14/6804.rst b/doc/build/changelog/unreleased_14/6804.rst
deleted file mode 100644
index 389da2c85..000000000
--- a/doc/build/changelog/unreleased_14/6804.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. change::
-    :tags: usecase, mypy
-    :tickets: 6804, 6759
-
-    Added support for SQLAlchemy classes to be defined in user code using
-    "generic class" syntax as defined by ``sqlalchemy2-stubs``, e.g.
-    ``Column[String]``, without the need for qualifying these constructs within
-    a ``TYPE_CHECKING`` block by implementing the Python special method
-    ``__class_getitem__()``, which allows this syntax to pass without error at
-    runtime.
diff --git a/doc/build/changelog/unreleased_14/6808.rst b/doc/build/changelog/unreleased_14/6808.rst
deleted file mode 100644
index 803a94482..000000000
--- a/doc/build/changelog/unreleased_14/6808.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-.. change::
-    :tags: orm, usecase
-    :tickets: 6808
-
-    Added new attribute :attr:`_sql.Select.columns_clause_froms` that will
-    retrieve the FROM list implied by the columns clause of the
-    :class:`_sql.Select` statement. This differs from the old
-    :attr:`_sql.Select.froms` collection in that it does not perform any ORM
-    compilation steps, which necessarily deannotate the FROM elements and do
-    things like compute joinedloads etc., which makes it not an appropriate
-    candidate for the :meth:`_sql.Select.select_from` method. Additionally adds
-    a new parameter
-    :paramref:`_sql.Select.with_only_columns.maintain_column_froms` that
-    transfers this collection to :meth:`_sql.Select.select_from` before
-    replacing the columns collection.
-
-    In addition, the :attr:`_sql.Select.froms` is renamed to
-    :meth:`_sql.Select.get_final_froms`, to stress that this collection is not
-    a simple accessor and is instead calculated given the full state of the
-    object, which can be an expensive call when used in an ORM context.
-
-    Additionally fixes a regression involving the
-    :func:`_orm.with_only_columns` function to support applying criteria to
-    column elements that were replaced with either
-    :meth:`_sql.Select.with_only_columns` or :meth:`_orm.Query.with_entities` ,
-    which had broken as part of :ticket:`6503` released in 1.4.19.
diff --git a/doc/build/changelog/unreleased_14/6812.rst b/doc/build/changelog/unreleased_14/6812.rst
deleted file mode 100644
index d91db2e90..000000000
--- a/doc/build/changelog/unreleased_14/6812.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 6812
-
-    Fixed issue where the unit of work would internally use a 2.0-deprecated
-    SQL expression form, emitting a deprecation warning when SQLALCHEMY_WARN_20
-    were enabled.
-
diff --git a/doc/build/changelog/unreleased_14/6816.rst b/doc/build/changelog/unreleased_14/6816.rst
deleted file mode 100644
index f778fc11b..000000000
--- a/doc/build/changelog/unreleased_14/6816.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. change::
-    :tags: bug, ext
-    :tickets: 6816
-
-    Fixed issue where the horizontal sharding extension would not correctly
-    accommodate for a plain textual SQL statement passed to
-    :meth:`_orm.Session.execute`.
diff --git a/doc/build/changelog/unreleased_14/6824.rst b/doc/build/changelog/unreleased_14/6824.rst
deleted file mode 100644
index 48086e0ed..000000000
--- a/doc/build/changelog/unreleased_14/6824.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. change::
-    :tags: bug, orm, sql
-    :tickets: 6824
-
-    Fixed issue where a bound parameter object that was "cloned" would cause a
-    name conflict in the compiler, if more than one clone of this parameter
-    were used at the same time in a single statement. This could occur in
-    particular with things like ORM single table inheritance queries that
-    indicated the same "discriminator" value multiple times in one query.
-
diff --git a/doc/build/changelog/unreleased_14/6858.rst b/doc/build/changelog/unreleased_14/6858.rst
deleted file mode 100644
index 0aa9d7538..000000000
--- a/doc/build/changelog/unreleased_14/6858.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. change::
-    :tags: bug, sql
-    :tickets: 6858
-
-    Fixed an issue in the ``CacheKey.to_offline_string()`` method used by the
-    dogpile.caching example where attempting to create a proper cache key from
-    the special "lambda" query generated by the lazy loader would fail to
-    include the parameter values, leading to an incorrect cache key.
-
diff --git a/doc/build/changelog/unreleased_14/6863.rst b/doc/build/changelog/unreleased_14/6863.rst
deleted file mode 100644
index 8dc90c4ad..000000000
--- a/doc/build/changelog/unreleased_14/6863.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. change::
-    :tags: bug, mssql, sql
-    :tickets: 6863
-
-    Fixed issue where the ``literal_binds`` compiler flag, as used externally
-    to render bound parameters inline, would fail to work when used with a
-    certain class of parameters known as "literal_execute", which covers things
-    like LIMIT and OFFSET values for dialects where the drivers don't allow a
-    bound parameter, such as SQL Server's "TOP" clause.  The issue locally
-    seemed to affect only the MSSQL dialect.
diff --git a/doc/build/changelog/unreleased_14/6869.rst b/doc/build/changelog/unreleased_14/6869.rst
deleted file mode 100644
index 601da86ba..000000000
--- a/doc/build/changelog/unreleased_14/6869.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 6869
-
-    Fixed issue in loader strategies where the use of the
-    :meth:`_orm.Load.options` method, particularly when nesting multiple calls,
-    would generate an overly long and more importantly non-deterministic cache
-    key, leading to very large cache keys which were also not allowing
-    efficient cache usage, both in terms of total memory used as well as number
-    of entries used in the cache itself.
diff --git a/doc/build/changelog/unreleased_14/6881.rst b/doc/build/changelog/unreleased_14/6881.rst
deleted file mode 100644
index aab17e396..000000000
--- a/doc/build/changelog/unreleased_14/6881.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 6881
-
-    Fixed issue in :func:`_orm.selectinload` where use of the new
-    :meth:`_orm.PropComparator.and_` feature within options that were nested
-    more than one level deep would fail to update bound parameter values that
-    were in the nested criteria, as a side effect of SQL statement caching.
-
diff --git a/doc/build/changelog/unreleased_14/6886.rst b/doc/build/changelog/unreleased_14/6886.rst
deleted file mode 100644
index b4899912b..000000000
--- a/doc/build/changelog/unreleased_14/6886.rst
+++ /dev/null
@@ -1,18 +0,0 @@
-.. change::
-    :tags: bug, sql
-    :tickets: 6886
-
-    Adjusted the "from linter" warning feature to accommodate for a chain of
-    joins more than one level deep where the ON clauses don't explicitly match
-    up the targets, such as an expression such as "ON TRUE". This mode of use
-    is intended to cancel the cartesian product warning simply by the fact that
-    there's a JOIN from "a to b", which was not working for the case where the
-    chain of joins had more than one element.
-
-.. change::
-    :tags: bug, postgresql
-    :tickets: 6886
-
-    Added the "is_comparison" flag to the PostgreSQL "overlaps",
-    "contained_by", "contains" operators, so that they work in relevant ORM
-    contexts as well as in conjunction with the "from linter" feature.
diff --git a/doc/build/changelog/unreleased_14/6887.rst b/doc/build/changelog/unreleased_14/6887.rst
deleted file mode 100644
index 8992dccba..000000000
--- a/doc/build/changelog/unreleased_14/6887.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 6887
-
-    Revised the means by which the
-    :attr:`_orm.ORMExecuteState.user_defined_options` accessor receives
-    :class:`_orm.UserDefinedOption` and related option objects from the
-    context, with particular emphasis on the "selectinload" on the loader
-    strategy where this previously was not working; other strategies did not
-    have this problem. The objects that are associated with the current query
-    being executed, and not that of a query being cached, are now propagated
-    unconditionally. This essentially separates them out from the "loader
-    strategy" options which are explicitly associated with the compiled state
-    of a query and need to be used in relation to the cached query.
-
-    The effect of this fix is that a user-defined option, such as those used
-    by the dogpile.caching example as well as for other recipes such as
-    defining a "shard id" for the horizontal sharing extension, will be
-    correctly propagated to eager and lazy loaders regardless of whether
-    a cached query was ultimately invoked.
-
diff --git a/doc/build/changelog/unreleased_14/6889.rst b/doc/build/changelog/unreleased_14/6889.rst
deleted file mode 100644
index fe3c24050..000000000
--- a/doc/build/changelog/unreleased_14/6889.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 6889, 6079
-
-    Adjusted ORM loader internals to no longer use the "lambda caching" system
-    that was added in 1.4, as well as repaired one location that was still
-    using the previous "baked query" system for a query. The lambda caching
-    system remains an effective way to reduce the overhead of building up
-    queries that have relatively fixed usage patterns. In the case of loader
-    strategies, the queries used are responsible for moving through lots of
-    arbitrary options and criteria, which is both generated and sometimes
-    consumed by end-user code, that make the lambda cache concept not any more
-    efficient than not using it, at the cost of more complexity. In particular
-    the problems noted by :ticket:`6881` and :ticket:`6887` are made are made
-    considerably less complicated by removing this feature internally.
-
-
-
-.. change::
-    :tags: bug, orm
-    :tickets: 6889
-
-    Fixed an issue where the :class:`_orm.Bundle` construct would not create
-    proper cache keys, leading to inefficient use of the query cache.  This
-    had some impact on the "selectinload" strategy and was identified as
-    part of :ticket:`6889`.
diff --git a/doc/build/changelog/unreleased_14/lmb_no_cache.rst b/doc/build/changelog/unreleased_14/lmb_no_cache.rst
deleted file mode 100644
index 4f6e19320..000000000
--- a/doc/build/changelog/unreleased_14/lmb_no_cache.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. change::
-    :tags: bug, sql
-
-    Fixed issue in lambda caching system where an element of a query that
-    produces no cache key, like a custom option or clause element, would still
-    populate the expression in the "lambda cache" inappropriately.
diff --git a/doc/build/conf.py b/doc/build/conf.py
index d56d7d914..a1232f51f 100644
--- a/doc/build/conf.py
+++ b/doc/build/conf.py
@@ -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.22"
+release = "1.4.23"
 
-release_date = "July 21, 2021"
+release_date = "August 18, 2021"
 
 site_base = os.environ.get("RTD_SITE_BASE", "https://www.sqlalchemy.org")
 site_adapter_template = "docs_adapter.mako"