: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.
: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.
: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::
:tags: bug, engine
: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.
: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.
: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.
-
- 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.
+ 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` 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.
: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.
.. 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.
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
