.. 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
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
