From: Mike Bayer Date: Wed, 18 Aug 2021 17:05:20 +0000 (-0400) Subject: - 1.4.23 X-Git-Tag: rel_1_4_23 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=dbca3582f9aa105f9c0ddf4eba5b4130f297ad7d;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git - 1.4.23 --- diff --git a/doc/build/changelog/changelog_14.rst b/doc/build/changelog/changelog_14.rst index 72e4a2d222..8426e6de8e 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 de3b2feb1e..0000000000 --- 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 418fbc4e2b..0000000000 --- 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 9cc07c2a1d..0000000000 --- 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 389da2c85a..0000000000 --- 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 803a944823..0000000000 --- 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 d91db2e90e..0000000000 --- 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 f778fc11b7..0000000000 --- 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 48086e0ed0..0000000000 --- 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 0aa9d75380..0000000000 --- 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 8dc90c4adf..0000000000 --- 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 601da86ba4..0000000000 --- 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 aab17e3965..0000000000 --- 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 b4899912b8..0000000000 --- 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 8992dccba0..0000000000 --- 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 fe3c240502..0000000000 --- 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 4f6e193201..0000000000 --- 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 d56d7d914e..a1232f51fd 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"