From: Mike Bayer Date: Fri, 4 Nov 2022 20:16:48 +0000 (-0400) Subject: changelog updates X-Git-Tag: rel_2_0_0b3~5 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=751469240a1f2908d16ca2b087b5dac55dbdcb47;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git changelog updates as this release cycle was fairly frenetic, a lot of these changelogs were very poorly worded (by me). Change-Id: Idb796cf3e25975fb2f75bacf26f1cb57ef0e4cad --- diff --git a/doc/build/changelog/unreleased_14/8700.rst b/doc/build/changelog/unreleased_14/8700.rst index 205f251ef4..0805c23384 100644 --- a/doc/build/changelog/unreleased_14/8700.rst +++ b/doc/build/changelog/unreleased_14/8700.rst @@ -2,9 +2,9 @@ :tags: bug, mssql, reflection :tickets: 8700 - Fixed issue with :meth:`.Inspector.has_table` when used against a view for - 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 + Fixed issue with :meth:`.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. diff --git a/doc/build/changelog/unreleased_14/8704.rst b/doc/build/changelog/unreleased_14/8704.rst index 7327c95313..90d9728706 100644 --- a/doc/build/changelog/unreleased_14/8704.rst +++ b/doc/build/changelog/unreleased_14/8704.rst @@ -3,6 +3,6 @@ :tickets: 8704 Fixed issue where "selectin_polymorphic" loading for inheritance mappers - would not function correctly if the :param:`_orm.Mapper.polymorphic_on` + would not function correctly if the :paramref:`_orm.Mapper.polymorphic_on` parameter referred to a SQL expression that was not directly mapped on the class. diff --git a/doc/build/changelog/unreleased_14/8710.rst b/doc/build/changelog/unreleased_14/8710.rst index c687d4f838..e6f9211092 100644 --- a/doc/build/changelog/unreleased_14/8710.rst +++ b/doc/build/changelog/unreleased_14/8710.rst @@ -3,23 +3,24 @@ :tickets: 8710 Fixed issue where the underlying DBAPI cursor would not be closed when - using :class:`_orm.Query` and direct iteration, if a user-defined exception - case were raised within the iteration process, interrupting the iterator - which otherwise is not possible to re-use in this context. When using + using the :class:`_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 :meth:`_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. + to the usual MySQL-related issues with server side cursors out of sync, + and without direct access to the :class:`.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 default - iterator, which applies only in those cases where the interpreter is - calling ``.close()`` on the iterator in any case. + 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. - A similar scenario can occur when using :term:`2.x` executions with direct - use of :class:`.Result`, in that case the end-user code has access to the - :class:`.Result` itself and should call :meth:`.Result.close` directly. - Version 2.0 will feature context-manager calling patterns to address this - use case. However within the 1.4 scope, ensured that ``.close()`` methods - are available on all :class:`.Result` implementations including - :class:`.ScalarResult`, :class:`.MappingResult`. + As part of this change as implemented for the 1.4 series, ensured that + ``.close()`` methods are available on all :class:`.Result` implementations + including :class:`.ScalarResult`, :class:`.MappingResult`. The 2.0 + version of this change also includes new context manager patterns for use + with :class:`.Result` classes. .. change:: diff --git a/doc/build/changelog/unreleased_14/8711.rst b/doc/build/changelog/unreleased_14/8711.rst index 82e68bbc43..cc76eb461c 100644 --- a/doc/build/changelog/unreleased_14/8711.rst +++ b/doc/build/changelog/unreleased_14/8711.rst @@ -2,8 +2,9 @@ :tags: bug, orm :tickets: 8711 - Fixed the exception that's raised when the - :func:`_orm.with_loader_criteria` option is attempted to be used within a - specific loader path, like in loader.options(). - :func:`_orm.with_loader_criteria` is only intended to be used at the top - level. + An informative exception is now raised when the + :func:`_orm.with_loader_criteria` option is used as a loader option added + to a specific "loader path", such as when using it within + :meth:`.Load.options`. This use is not supported as + :func:`_orm.with_loader_criteria` is only intended to be used as a top + level loader option. Previously, an internal error would be generated. diff --git a/doc/build/changelog/unreleased_14/8714.rst b/doc/build/changelog/unreleased_14/8714.rst index d75f2570ed..6fd133a091 100644 --- a/doc/build/changelog/unreleased_14/8714.rst +++ b/doc/build/changelog/unreleased_14/8714.rst @@ -2,7 +2,7 @@ :tags: bug, mssql :tickets: 8714 - Fixed issue with :meth:`.Inspector.has_table` when used against a temporary - table for the SQL Server dialect would fail an invalid object name error on - some Azure variants, due to an unnecessary information schema query that is - not supported on those server versions. Pull request courtesy Mike Barry. + Fixed issue with :meth:`.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. diff --git a/doc/build/changelog/unreleased_14/8717.rst b/doc/build/changelog/unreleased_14/8717.rst index ee5fa59490..dba7b830c6 100644 --- a/doc/build/changelog/unreleased_14/8717.rst +++ b/doc/build/changelog/unreleased_14/8717.rst @@ -3,16 +3,21 @@ :tickets: 8717 Fixed issue where the :meth:`.PoolEvents.reset` event hook would not be - called when a :class:`.Connection` were closed which already called - ``.rollback()`` on its own transaction, due to an enhancement in the 1.4 - series that ensures ``.rollback()`` is only called once in this scenario, - rather than twice. This would prevent custom pool reset schemes from being - used within this hook. This was a regression that appeared in version 1.4. + be called in all cases when a :class:`.Connection` were closed and was + in the process of returning its DBAPI connection to the connection pool. + The scenario was when the :class:`.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 :meth:`.PoolEvents.checkin` likely remains a better - event to use for custom "reset" implementations. Version 2.0 will feature - an improved version of :meth:`.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. + For version 1.4, the :meth:`.PoolEvents.checkin` remains viable as an + alternate event hook to use for custom "reset" implementations. Version 2.0 + will feature an improved version of :meth:`.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. diff --git a/doc/build/changelog/unreleased_14/8721.rst b/doc/build/changelog/unreleased_14/8721.rst index e6d7f4bf4c..9e62e66b53 100644 --- a/doc/build/changelog/unreleased_14/8721.rst +++ b/doc/build/changelog/unreleased_14/8721.rst @@ -2,16 +2,13 @@ :tags: bug, orm :tickets: 8721 - Fixed bug involving :class:`.Select` constructs which used a combination of - :meth:`.Select.select_from` with an ORM entity followed by - :meth:`.Select.join` against the entity sent in - :meth:`.Select.select_from`, as well as using plain - :meth:`.Select.join_from`, which when combined with a columns clause that - didn't explicitly include that entity would then cause "automatic WHERE - criteria" features such as the IN expression required for a single-table - inheritance subclass, as well as the criteria set up by the - :func:`_orm.with_loader_criteria` option, to not be rendered for that - entity. The correct entity is now transferred to the :class:`.Join` object - that's generated internally, so that the criteria against the left - side entity is correctly added. + Fixed bug involving :class:`.Select` constructs, where combinations of + :meth:`.Select.select_from` with :meth:`.Select.join`, as well as when + using :meth:`.Select.join_from`, would cause the + :func:`_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 + :class:`.Join` object that's generated internally, so that the criteria + against the left side entity is correctly added. diff --git a/doc/build/changelog/unreleased_14/8738.rst b/doc/build/changelog/unreleased_14/8738.rst index 2372c25afe..fb7b31ac34 100644 --- a/doc/build/changelog/unreleased_14/8738.rst +++ b/doc/build/changelog/unreleased_14/8738.rst @@ -1,8 +1,9 @@ .. change:: :tags: bug, orm - :tickets: 8731 + :tickets: 8738 Fixed issue in joined eager loading where an assertion fail would occur - with a particular combination of outer/inner joined eager loads in - conjunction with an inherited subclass mapper as the middle target. + 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.