1.4.43

Released: November 4, 2022

orm

• [orm] [bug] Fixed issue in joined eager loading where an assertion fail would occur with a particular combination of outer/inner joined eager loads, when eager loading across three mappers where the middle mapper was an inherited subclass mapper.

  References: #8738

• [orm] [bug] Fixed bug involving Select constructs, where combinations of Select.select_from() with Select.join(), as well as when using Select.join_from(), would cause the _orm.with_loader_criteria() feature as well as the IN criteria needed for single-table inheritance queries to not render, in cases where the columns clause of the query did not explicitly include the left-hand side entity of the JOIN. The correct entity is now transferred to the Join object that's generated internally, so that the criteria against the left side entity is correctly added.

  References: #8721

• [orm] [bug] An informative exception is now raised when the _orm.with_loader_criteria() option is used as a loader option added to a specific "loader path", such as when using it within Load.options(). This use is not supported as _orm.with_loader_criteria() is only intended to be used as a top level loader option. Previously, an internal error would be generated.

  References: #8711

• [orm] [bug] Improved "dictionary mode" for _orm.Session.get() so that synonym names which refer to primary key attribute names may be indicated in the named dictionary.

  References: #8753

• [orm] [bug] Fixed issue where "selectin_polymorphic" loading for inheritance mappers would not function correctly if the _orm.Mapper.polymorphic_on parameter referred to a SQL expression that was not directly mapped on the class.

  References: #8704

• [orm] [bug] Fixed issue where the underlying DBAPI cursor would not be closed when using the _orm.Query object as an iterator, if a user-defined exception case were raised within the iteration process, thereby causing the iterator to be closed by the Python interpreter. When using _orm.Query.yield_per() to create server-side cursors, this would lead to the usual MySQL-related issues with server side cursors out of sync, and without direct access to the Result object, end-user code could not access the cursor in order to close it.

  To resolve, a catch for GeneratorExit is applied within the iterator method, which will close the result object in those cases when the iterator were interrupted, and by definition will be closed by the Python interpreter.

  As part of this change as implemented for the 1.4 series, ensured that .close() methods are available on all Result implementations including ScalarResult, MappingResult. The 2.0 version of this change also includes new context manager patterns for use with Result classes.

  References: #8710

engine

• [engine] [bug] [regression] Fixed issue where the PoolEvents.reset() event hook would not be be called in all cases when a _engine.Connection were closed and was in the process of returning its DBAPI connection to the connection pool.

  The scenario was when the _engine.Connection had already emitted .rollback() on its DBAPI connection within the process of returning the connection to the pool, where it would then instruct the connection pool to forego doing its own "reset" to save on the additional method call. However, this prevented custom pool reset schemes from being used within this hook, as such hooks by definition are doing more than just calling .rollback(), and need to be invoked under all circumstances. This was a regression that appeared in version 1.4.

  For version 1.4, the PoolEvents.checkin() remains viable as an alternate event hook to use for custom "reset" implementations. Version 2.0 will feature an improved version of PoolEvents.reset() which is called for additional scenarios such as termination of asyncio connections, and is also passed contextual information about the reset, to allow for "custom connection reset" schemes which can respond to different reset scenarios in different ways.

  References: #8717

• [engine] [bug] Ensured all Result objects include a Result.close() method as well as a Result.closed attribute, including on ScalarResult and MappingResult.

  References: #8710

sql

• [sql] [bug] Fixed issue which prevented the _sql.literal_column() construct from working properly within the context of a Select construct as well as other potential places where "anonymized labels" might be generated, if the literal expression contained characters which could interfere with format strings, such as open parenthesis, due to an implementation detail of the "anonymous label" structure.

  References: #8724

mssql

• [mssql] [bug] Fixed issue with Inspector.has_table(), which when used against a temporary table with the SQL Server dialect would fail on some Azure variants, due to an unnecessary information schema query that is not supported on those server versions. Pull request courtesy Mike Barry.

  References: #8714

• [mssql] [bug] [reflection] Fixed issue with Inspector.has_table(), which when used against a view with the SQL Server dialect would erroneously return False, due to a regression in the 1.4 series which removed support for this on SQL Server. The issue is not present in the 2.0 series which uses a different reflection architecture. Test support is added to ensure has_table() remains working per spec re: views.

  References: #8700

oracle

• [oracle] [bug] Fixed issue where bound parameter names, including those automatically derived from similarly-named database columns, which contained characters that normally require quoting with Oracle would not be escaped when using "expanding parameters" with the Oracle dialect, causing execution errors. The usual "quoting" for bound parameters used by the Oracle dialect is not used with the "expanding parameters" architecture, so escaping for a large range of characters is used instead, now using a list of characters/escapes that are specific to Oracle.

  References: #8708

• [oracle] [bug] Fixed issue where the nls_session_parameters view queried on first connect in order to get the default decimal point character may not be available depending on Oracle connection modes, and would therefore raise an error. The approach to detecting decimal char has been simplified to test a decimal value directly, instead of reading system views, which works on any backend / driver.

  References: #8744