2.0.29

Released: March 23, 2024

orm

• [orm] [usecase] Added support for the PEP 695 TypeAliasType construct as well as the python 3.12 native type keyword to work with ORM Annotated Declarative form when using these constructs to link to a PEP 593 Annotated container, allowing the resolution of the Annotated to proceed when these constructs are used in a _orm.Mapped typing container.

  References: #11130

• [orm] [bug] Fixed Declarative issue where typing a relationship using _orm.Relationship rather than _orm.Mapped would inadvertently pull in the "dynamic" relationship loader strategy for that attribute.

  References: #10611

• [orm] [bug] Fixed issue in ORM annotated declarative where using _orm.mapped_column() with an _orm.mapped_column.index or _orm.mapped_column.unique setting of False would be overridden by an incoming Annotated element that featured that parameter set to True, even though the immediate _orm.mapped_column() element is more specific and should take precedence. The logic to reconcile the booleans has been enhanced to accommodate a local value of False as still taking precedence over an incoming True value from the annotated element.

  References: #11091

• [orm] [bug] [regression] Fixed regression from version 2.0.28 caused by the fix for #11085 where the newer method of adjusting post-cache bound parameter values would interefere with the implementation for the _orm.subqueryload() loader option, which has some more legacy patterns in use internally, when the additional loader criteria feature were used with this loader option.

  References: #11173

engine

• [engine] [bug] Fixed issue in engine_insertmanyvalues feature where using a primary key column with an "inline execute" default generator such as an explicit Sequence with an explcit schema name, while at the same time using the _engine.Connection.execution_options.schema_translate_map feature would fail to render the sequence or the parameters properly, leading to errors.

  References: #11157

• [engine] [bug] Made a change to the adjustment made in version 2.0.10 for #9618, which added the behavior of reconciling RETURNING rows from a bulk INSERT to the parameters that were passed to it. This behavior included a comparison of already-DB-converted bound parameter values against returned row values that was not always "symmetrical" for SQL column types such as UUIDs, depending on specifics of how different DBAPIs receive such values versus how they return them, necessitating the need for additional "sentinel value resolver" methods on these column types. Unfortunately this broke third party column types such as UUID/GUID types in libraries like SQLModel which did not implement this special method, raising an error "Can't match sentinel values in result set to parameter sets". Rather than attempt to further explain and document this implementation detail of the "insertmanyvalues" feature including a public version of the new method, the approach is intead revised to no longer need this extra conversion step, and the logic that does the comparison now works on the pre-converted bound parameter value compared to the post-result-processed value, which should always be of a matching datatype. In the unusual case that a custom SQL column type that also happens to be used in a "sentinel" column for bulk INSERT is not receiving and returning the same value type, the "Can't match" error will be raised, however the mitigation is straightforward in that the same Python datatype should be passed as that returned.

  References: #11160

sql

• [sql] [bug] [regression] Fixed regression from the 1.4 series where the refactor of the _types.TypeEngine.with_variant() method introduced at change_6980 failed to accommodate for the .copy() method, which will lose the variant mappings that are set up. This becomes an issue for the very specific case of a "schema" type, which includes types such as Enum and ARRAY, when they are then used in the context of an ORM Declarative mapping with mixins where copying of types comes into play. The variant mapping is now copied as well.

  References: #11176

typing

• [typing] [bug] Fixed typing issue allowing asyncio run_sync() methods to correctly type the parameters according to the callable that was passed, making use of PEP 612 ParamSpec variables. Pull request courtesy Francisco R. Del Roio.

  References: #11055

postgresql

• [postgresql] [usecase] The PostgreSQL dialect now returns _postgresql.DOMAIN instances when reflecting a column that has a domain as type. Previously, the domain data type was returned instead. As part of this change, the domain reflection was improved to also return the collation of the text types. Pull request courtesy of Thomas Stephenson.

  References: #10693

tests

• [tests] [bug] Backported to SQLAlchemy 2.0 an improvement to the test suite with regards to how asyncio related tests are run, now using the newer Python 3.11 asyncio.Runner or a backported equivalent, rather than relying on the previous implementation based on asyncio.get_running_loop(). This should hopefully prevent issues with large suite runs on CPU loaded hardware where the event loop seems to become corrupted, leading to cascading failures.

  References: #11187