1.4.28

Released: December 9, 2021

platform

• [platform] [bug] Python 3.10 has deprecated "distutils" in favor of explicit use of "setuptools" in PEP 632; SQLAlchemy's setup.py has replaced imports accordingly. However, since setuptools itself only recently added the replacement symbols mentioned in pep-632 as of November of 2021 in version 59.0.1, setup.py still has fallback imports to distutils, as SQLAlchemy 1.4 does not have a hard setuptools versioning requirement at this time. SQLAlchemy 2.0 is expected to use a full PEP 517 installation layout which will indicate appropriate setuptools versioning up front.

  References: #7311

orm

• [orm] [bug] [ext] Fixed issue where the internal cloning used by the _orm.PropComparator.any() method on a _orm.relationship() in the case where the related class also makes use of ORM polymorphic loading, would fail if a hybrid property on the related, polymorphic class were used within the criteria for the any() operation.

  References: #7425

• [orm] [bug] [mypy] Fixed issue where the _orm.as_declarative() decorator and similar functions used to generate the declarative base class would not copy the __class_getitem__() method from a given superclass, which prevented the use of pep-484 generics in conjunction with the Base class. Pull request courtesy Kai Mueller.

  References: #7368

• [orm] [bug] [regression] Fixed ORM regression where the new behavior of "eager loaders run on unexpire" added in #1763 would lead to loader option errors being raised inappropriately for the case where a single _orm.Query or _sql.Select were used to load multiple kinds of entities, along with loader options that apply to just one of those kinds of entity like a _orm.joinedload(), and later the objects would be refreshed from expiration, where the loader options would attempt to be applied to the mismatched object type and then raise an exception. The check for this mismatch now bypasses raising an error for this case.

  References: #7318

• [orm] [bug] User defined ORM options, such as those illustrated in the dogpile.caching example which subclass _orm.UserDefinedOption, by definition are handled on every statement execution and do not need to be considered as part of the cache key for the statement. Caching of the base ExecutableOption class has been modified so that it is no longer a HasCacheKey subclass directly, so that the presence of user defined option objects will not have the unwanted side effect of disabling statement caching. Only ORM specific loader and criteria options, which are all internal to SQLAlchemy, now participate within the caching system.

  References: #7394

• [orm] [bug] Fixed issue where mappings that made use of _orm.synonym() and potentially other kinds of "proxy" attributes would not in all cases successfully generate a cache key for their SQL statements, leading to degraded performance for those statements.

  References: #7394

• [orm] [bug] Fixed issue where a list mapped with _orm.relationship() would go into an endless loop if in-place added to itself, i.e. the += operator were used, as well as if .extend() were given the same list.

  References: #7389

• [orm] [bug] Fixed issue where if an exception occurred when the _orm.Session were to close the connection within the _orm.Session.commit() method, when using a context manager for _orm.Session.begin() , it would attempt a rollback which would not be possible as the _orm.Session was in between where the transaction is committed and the connection is then to be returned to the pool, raising the exception "this sessiontransaction is in the committed state". This exception can occur mostly in an asyncio context where CancelledError can be raised.

  References: #7388

• [orm] [deprecated] Deprecated an undocumented loader option syntax ".*", which appears to be no different than passing a single asterisk, and will emit a deprecation warning if used. This syntax may have been intended for something but there is currently no need for it.

  References: #4390

engine

• [engine] [usecase] Added support for copy() and deepcopy() to the _url.URL class. Pull request courtesy Tom Ritchford.

  References: #7400

sql

• [sql] [usecase] "Compound select" methods like _sql.Select.union(), _sql.Select.intersect_all() etc. now accept *other as an argument rather than other to allow for multiple additional SELECTs to be compounded with the parent statement at once. In particular, the change as applied to _sql.CTE.union() and _sql.CTE.union_all() now allow for a so-called "non-linear CTE" to be created with the _sql.CTE construct, whereas previously there was no way to have more than two CTE sub-elements in a UNION together while still correctly calling upon the CTE in recursive fashion. Pull request courtesy Eric Masseran.

  References: #7259

• [sql] [usecase] Support multiple clause elements in the _sql.Exists.where() method, unifying the api with the one presented by a normal _sql.select() construct.

  References: #7386

• [sql] [bug] [regression] Extended the TypeDecorator.cache_ok attribute and corresponding warning message if this flag is not defined, a behavior first established for TypeDecorator as part of #6436, to also take place for UserDefinedType, by generalizing the flag and associated caching logic to a new common base for these two types, ExternalType to create UserDefinedType.cache_ok.

  The change means any current UserDefinedType will now cause SQL statement caching to no longer take place for statements which make use of the datatype, along with a warning being emitted, unless the class defines the UserDefinedType.cache_ok flag as True. If the datatype cannot form a deterministic, hashable cache key derived from its arguments, the attribute may be set to False which will continue to keep caching disabled but will suppress the warning. In particular, custom datatypes currently used in packages such as SQLAlchemy-utils will need to implement this flag. The issue was observed as a result of a SQLAlchemy-utils datatype that is not currently cacheable.

  References: #7319

• [sql] [bug] Custom SQL elements, third party dialects, custom or third party datatypes will all generate consistent warnings when they do not clearly opt in or out of SQL statement caching, which is achieved by setting the appropriate attributes on each type of class. The warning links to documentation sections which indicate the appropriate approach for each type of object in order for caching to be enabled.

  References: #7394

• [sql] [bug] Fixed missing caching directives for a few lesser used classes in SQL Core which would cause [no key] to be logged for elements which made use of these.

  References: #7394

mypy

• [mypy] [bug] Fixed Mypy crash which would occur when using Mypy plugin against code which made use of _orm.declared_attr methods for non-mapped names like __mapper_args__, __table_args__, or other dunder names, as the plugin would try to interpret these as mapped attributes which would then be later mis-handled. As part of this change, the decorated function is still converted by the plugin into a generic assignment statement (e.g. __mapper_args__: Any) so that the argument signature can continue to be annotated in the same way one would for any other @classmethod without Mypy complaining about the wrong argument type for a method that isn't explicitly @classmethod.

  References: #7321

postgresql

• [postgresql] [bug] Fixed missing caching directives for _postgresql.hstore and _postgresql.array constructs which would cause [no key] to be logged for these elements.

  References: #7394

tests

• [tests] [bug] Implemented support for the test suite to run correctly under Pytest 7. Previously, only Pytest 6.x was supported for Python 3, however the version was not pinned on the upper bound in tox.ini. Pytest is not pinned in tox.ini to be lower than version 8 so that SQLAlchemy versions released with the current codebase will be able to be tested under tox without changes to the environment. Much thanks to the Pytest developers for their help with this issue.