delta/python-packages/sqlalchemy.git/test/sql/test_resultset.py, branch rel_1_4 github.com: zzzeek/sqlalchemy.git look out for extras=None in freeze 2022-12-09T20:58:04+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-12-09T20:56:15+00:00 c60ff04d671558c02d8f8eb1ea6470f896538f78 Fixed issue where :meth:`_engine.Result.freeze` method would not work for textual SQL using either :func:`_sql.text` or :meth:`_engine.Connection.exec_driver_sql`. Fixes: #8963 Change-Id: Ia131c6ac41a4adf32eb1bf1abf23930ef395f16c (cherry picked from commit 44170aee47a021883c6244f702de2e4385a5cd1d) 
Fixed issue where :meth:`_engine.Result.freeze` method would not work for
textual SQL using either :func:`_sql.text` or
:meth:`_engine.Connection.exec_driver_sql`.

Fixes: #8963
Change-Id: Ia131c6ac41a4adf32eb1bf1abf23930ef395f16c
(cherry picked from commit 44170aee47a021883c6244f702de2e4385a5cd1d)
soft close cursor for Query direct iterator interrupted 2022-11-03T19:56:59+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-11-01T19:09:25+00:00 a333d1c3a51099447fab47d3d0d03b3b61c268e4 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 :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 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. 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`. Fixes: #8710 Change-Id: I3166328bfd3900957eb33cbf1061d0495c9df670 
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
: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 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.

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`.

Fixes: #8710
Change-Id: I3166328bfd3900957eb33cbf1061d0495c9df670
break out text() from TextualSelect for col matching 2022-09-20T01:50:03+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-09-19T13:40:40+00:00 bbd90a987eea70c28dd1e2ee7007722b16ec9f74 Fixed issue where mixing "*" with additional explicitly-named column expressions within the columns clause of a :func:`_sql.select` construct would cause result-column targeting to sometimes consider the label name or other non-repeated names to be an ambiguous target. Fixes: #8536 Change-Id: I3c845eaf571033e54c9208762344f67f4351ac3a (cherry picked from commit 78327d98be9236c61f950526470f29b184dabba6) 
Fixed issue where mixing "*" with additional explicitly-named column
expressions within the columns clause of a :func:`_sql.select` construct
would cause result-column targeting to sometimes consider the label name or
other non-repeated names to be an ambiguous target.

Fixes: #8536
Change-Id: I3c845eaf571033e54c9208762344f67f4351ac3a
(cherry picked from commit 78327d98be9236c61f950526470f29b184dabba6)
fill out all distinguising fields for AliasedInsp 2022-08-17T20:53:38+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-08-17T17:06:51+00:00 9cd7cca2c70e87c852af7e570aabdfa7463ce645 Hardened the cache key strategy for the :func:`_orm.aliased` and :func:`_orm.with_polymorphic` constructs. While no issue involving actual statements being cached can easily be demonstrated (if at all), these two constructs were not including enough of what makes them unique in their cache keys for caching on the aliased construct alone to be accurate. Fixes: #8401 Change-Id: I13d14985b6965f398edd9494601d8ae89ac641f2 (cherry picked from commit a58f1b9c698dc7be29d43f2c4c21de8918943f77) 
Hardened the cache key strategy for the :func:`_orm.aliased` and
:func:`_orm.with_polymorphic` constructs. While no issue involving actual
statements being cached can easily be demonstrated (if at all), these two
constructs were not including enough of what makes them unique in their
cache keys for caching on the aliased construct alone to be accurate.

Fixes: #8401
Change-Id: I13d14985b6965f398edd9494601d8ae89ac641f2
(cherry picked from commit a58f1b9c698dc7be29d43f2c4c21de8918943f77)
repair yield_per for non-SS dialects and add new options 2022-07-01T16:14:58+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-06-30T23:10:06+00:00 06685f392d2e36981b4073b902539ad966c57327 Implemented new :paramref:`_engine.Connection.execution_options.yield_per` execution option for :class:`_engine.Connection` in Core, to mirror that of the same :ref:`yield_per <orm_queryguide_yield_per>` option available in the ORM. The option sets both the :paramref:`_engine.Connection.execution_options.stream_results` option at the same time as invoking :meth:`_engine.Result.yield_per`, to provide the most common streaming result configuration which also mirrors that of the ORM use case in its usage pattern. Fixed bug in :class:`_engine.Result` where the usage of a buffered result strategy would not be used if the dialect in use did not support an explicit "server side cursor" setting, when using :paramref:`_engine.Connection.execution_options.stream_results`. This is in error as DBAPIs such as that of SQLite and Oracle already use a non-buffered result fetching scheme, which still benefits from usage of partial result fetching. The "buffered" strategy is now used in all cases where :paramref:`_engine.Connection.execution_options.stream_results` is set. Added :meth:`.FilterResult.yield_per` so that result implementations such as :class:`.MappingResult`, :class:`.ScalarResult` and :class:`.AsyncResult` have access to this method. Fixes: #8199 Change-Id: I6dde3cbe483a1bf81e945561b60f4b7d1c434750 (cherry picked from commit e5a0cdb2eaa1d7f381e93d0529a7f8e6d5888877) 
Implemented new :paramref:`_engine.Connection.execution_options.yield_per`
execution option for :class:`_engine.Connection` in Core, to mirror that of
the same :ref:`yield_per <orm_queryguide_yield_per>` option available in
the ORM. The option sets both the
:paramref:`_engine.Connection.execution_options.stream_results` option at
the same time as invoking :meth:`_engine.Result.yield_per`, to provide the
most common streaming result configuration which also mirrors that of the
ORM use case in its usage pattern.

Fixed bug in :class:`_engine.Result` where the usage of a buffered result
strategy would not be used if the dialect in use did not support an
explicit "server side cursor" setting, when using
:paramref:`_engine.Connection.execution_options.stream_results`. This is in
error as DBAPIs such as that of SQLite and Oracle already use a
non-buffered result fetching scheme, which still benefits from usage of
partial result fetching.   The "buffered" strategy is now used in all
cases where :paramref:`_engine.Connection.execution_options.stream_results`
is set.

Added :meth:`.FilterResult.yield_per` so that result implementations
such as :class:`.MappingResult`, :class:`.ScalarResult` and
:class:`.AsyncResult` have access to this method.

Fixes: #8199
Change-Id: I6dde3cbe483a1bf81e945561b60f4b7d1c434750
(cherry picked from commit e5a0cdb2eaa1d7f381e93d0529a7f8e6d5888877)
implement correct errors for Row immutability 2021-12-09T19:24:29+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-12-09T19:23:42+00:00 5ae1c14f4c8cd1629b1730cd146cb2a71561b5e2 Corrected the error message for the ``AttributeError`` that's raised when attempting to write to an attribute on the :class:`_result.Row` class, which is immutable. The previous message claimed the column didn't exist which is misleading. Fixes: #7432 Change-Id: If0e2cbd3f763dca6c99a18aa42252c69f1207d59 (cherry picked from commit f113e979219e20a22044c4b262e4531ba9993b8a) 
Corrected the error message for the ``AttributeError`` that's raised when
attempting to write to an attribute on the :class:`_result.Row` class,
which is immutable. The previous message claimed the column didn't exist
which is misleading.

Fixes: #7432
Change-Id: If0e2cbd3f763dca6c99a18aa42252c69f1207d59
(cherry picked from commit f113e979219e20a22044c4b262e4531ba9993b8a)
Warn when caching is disabled / document 2021-12-06T23:28:50+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-12-03T19:04:05+00:00 8d5ed4c39eed6a13397f43159278138bbe1a4a1b This patch adds new warnings for all elements that don't indicate their caching behavior, including user-defined ClauseElement subclasses and third party dialects. it additionally adds new documentation to discuss an apparent performance degradation in 1.4 when caching is disabled as a result in the significant expense incurred by ORM lazy loaders, which in 1.3 used BakedQuery so were actually cached. As a result of adding the warnings, a fair degree of lesser used SQL expression objects identified that they did not define caching behavior so would have been producing ``[no key]``, including PostgreSQL constructs ``hstore`` and ``array``. These have been amended to use inherit cache where appropriate. "on conflict" constructs in PostgreSQL, MySQL, SQLite still explicitly don't generate a cache key at this time. The change also adds a test for all constructs via assert_compile() to assert they will not generate cache warnings. Fixes: #7394 Change-Id: I85958affbb99bfad0f5efa21bc8f2a95e7e46981 (cherry picked from commit 22deafe15289d2be55682e1632016004b02b62c0) 
This patch adds new warnings for all elements that
don't indicate their caching behavior, including user-defined
ClauseElement subclasses and third party dialects.
it additionally adds new documentation to discuss an apparent
performance degradation in 1.4 when caching is disabled as a
result in the significant expense incurred by ORM
lazy loaders, which in 1.3 used BakedQuery so were actually
cached.

As a result of adding the warnings, a fair degree of
lesser used SQL expression objects identified that they did not
define caching behavior so would have been producing
``[no key]``, including PostgreSQL constructs ``hstore``
and ``array``.  These have been amended to use inherit
cache where appropriate.  "on conflict" constructs in
PostgreSQL, MySQL, SQLite still explicitly don't generate
a cache key at this time.

The change also adds a test for all constructs via
assert_compile() to assert they will not generate cache
warnings.

Fixes: #7394
Change-Id: I85958affbb99bfad0f5efa21bc8f2a95e7e46981
(cherry picked from commit 22deafe15289d2be55682e1632016004b02b62c0)
use tuple expansion if type._is_tuple, test for Sequence if no type 2021-11-05T15:55:24+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-11-05T14:18:42+00:00 9ee47d90d804dc815685d42913ad170e04c38659 Fixed regression where the row objects returned for ORM queries, which are now the normal :class:`_sql.Row` objects, would not be interpreted by the :meth:`_sql.ColumnOperators.in_` operator as tuple values to be broken out into individual bound parameters, and would instead pass them as single values to the driver leading to failures. The change to the "expanding IN" system now accommodates for the expression already being of type :class:`.TupleType` and treats values accordingly if so. In the uncommon case of using "tuple-in" with an untyped statement such as a textual statement with no typing information, a tuple value is detected for values that implement ``collections.abc.Sequence``, but that are not ``str`` or ``bytes``, as always when testing for ``Sequence``. Added :class:`.TupleType` to the top level ``sqlalchemy`` import namespace. Fixes: #7292 Change-Id: I8286387e3b3c3752b3bd4ae3560d4f31172acc22 (cherry picked from commit 0c44a1e77cfde0f841a4a64140314c6b833efdab) 
Fixed regression where the row objects returned for ORM queries, which are
now the normal :class:`_sql.Row` objects, would not be interpreted by the
:meth:`_sql.ColumnOperators.in_` operator as tuple values to be broken out
into individual bound parameters, and would instead pass them as single
values to the driver leading to failures. The change to the "expanding IN"
system now accommodates for the expression already being of type
:class:`.TupleType` and treats values accordingly if so. In the uncommon
case of using "tuple-in" with an untyped statement such as a textual
statement with no typing information, a tuple value is detected for values
that implement ``collections.abc.Sequence``, but that are not ``str`` or
``bytes``, as always when testing for ``Sequence``.

Added :class:`.TupleType` to the top level ``sqlalchemy`` import namespace.

Fixes: #7292
Change-Id: I8286387e3b3c3752b3bd4ae3560d4f31172acc22
(cherry picked from commit 0c44a1e77cfde0f841a4a64140314c6b833efdab)
ensure soft_close occurs for fetchmany with server side cursor 2021-11-02T20:31:22+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-11-02T14:58:01+00:00 e35b3f499d48ea2963d266bbf689c508cef60d8b Fixed regression where the :meth:`_engine.CursorResult.fetchmany` method would fail to autoclose a server-side cursor (i.e. when ``stream_results`` or ``yield_per`` is in use, either Core or ORM oriented results) when the results were fully exhausted. All :class:`_result.Result` objects will now consistently raise :class:`_exc.ResourceClosedError` if they are used after a hard close, which includes the "hard close" that occurs after calling "single row or value" methods like :meth:`_result.Result.first` and :meth:`_result.Result.scalar`. This was already the behavior of the most common class of result objects returned for Core statement executions, i.e. those based on :class:`_engine.CursorResult`, so this behavior is not new. However, the change has been extended to properly accommodate for the ORM "filtering" result objects returned when using 2.0 style ORM queries, which would previously behave in "soft closed" style of returning empty results, or wouldn't actually "soft close" at all and would continue yielding from the underlying cursor. As part of this change, also added :meth:`_result.Result.close` to the base :class:`_result.Result` class and implemented it for the filtered result implementations that are used by the ORM, so that it is possible to call the :meth:`_engine.CursorResult.close` method on the underlying :class:`_engine.CursorResult` when the the ``yield_per`` execution option is in use to close a server side cursor before remaining ORM results have been fetched. This was again already available for Core result sets but the change makes it available for 2.0 style ORM results as well. Fixes: #7274 Change-Id: Id4acdfedbcab891582a7f8edd2e2e7d20d868e53 (cherry picked from commit 33824a9c06ca555ad208a9925bc7b40fe489fc72) 
Fixed regression where the :meth:`_engine.CursorResult.fetchmany` method
would fail to autoclose a server-side cursor (i.e. when ``stream_results``
or ``yield_per`` is in use, either Core or ORM oriented results) when the
results were fully exhausted.

All :class:`_result.Result` objects will now consistently raise
:class:`_exc.ResourceClosedError` if they are used after a hard close,
which includes the "hard close" that occurs after calling "single row or
value" methods like :meth:`_result.Result.first` and
:meth:`_result.Result.scalar`. This was already the behavior of the most
common class of result objects returned for Core statement executions, i.e.
those based on :class:`_engine.CursorResult`, so this behavior is not new.
However, the change has been extended to properly accommodate for the ORM
"filtering" result objects returned when using 2.0 style ORM queries,
which would previously behave in "soft closed" style of returning empty
results, or wouldn't actually "soft close" at all and would continue
yielding from the underlying cursor.

As part of this change, also added :meth:`_result.Result.close` to the base
:class:`_result.Result` class and implemented it for the filtered result
implementations that are used by the ORM, so that it is possible to call
the :meth:`_engine.CursorResult.close` method on the underlying
:class:`_engine.CursorResult` when the the ``yield_per`` execution option
is in use to close a server side cursor before remaining ORM results have
been fetched. This was again already available for Core result sets but the
change makes it available for 2.0 style ORM results as well.

Fixes: #7274
Change-Id: Id4acdfedbcab891582a7f8edd2e2e7d20d868e53
(cherry picked from commit 33824a9c06ca555ad208a9925bc7b40fe489fc72)
fixes for usage of the null() and similar constants 2021-10-08T17:09:33+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-10-06T22:51:08+00:00 b7226379ac06c9a1a78e783deaa60c701b1b7e88 Adjusted the "column disambiguation" logic that's new in 1.4, where the same expression repeated gets an "extra anonymous" label, so that the logic more aggressively deduplicates those labels when the repeated element is the same Python expression object each time, as occurs in cases like when using "singleton" values like :func:`_sql.null`. This is based on the observation that at least some databases (e.g. MySQL, but not SQLite) will raise an error if the same label is repeated inside of a subquery. Related to :ticket:`7153`, fixed an issue where result column lookups would fail for "adapted" SELECT statements that selected for "constant" value expressions most typically the NULL expression, as would occur in such places as joined eager loading in conjunction with limit/offset. This was overall a regression due to issue :ticket:`6259` which removed all "adaption" for constants like NULL, "true", and "false", but this broke the case where the same adaption logic were used to match the constant to a labeled expression referring to the constant in a subquery. Fixes: #7153 Fixes: #7154 Change-Id: I43823343721b9e70524ea3f5e8f39dd543a3e92b 
Adjusted the "column disambiguation" logic that's new in 1.4, where the
same expression repeated gets an "extra anonymous" label, so that the logic
more aggressively deduplicates those labels when the repeated element
is the same Python expression object each time, as occurs in cases like
when using "singleton" values like :func:`_sql.null`.  This is based on
the observation that at least some databases (e.g. MySQL, but not SQLite)
will raise an error if the same label is repeated inside of a subquery.

Related to :ticket:`7153`, fixed an issue where result column lookups
would fail for "adapted" SELECT statements that selected for
"constant" value expressions most typically the NULL expression,
as would occur in such places as joined eager loading in conjunction
with limit/offset.  This was overall a regression due to issue
:ticket:`6259` which removed all "adaption" for constants like NULL,
"true", and "false", but this broke the case where the same adaption
logic were used to match the constant to a labeled expression referring
to the constant in a subquery.

Fixes: #7153
Fixes: #7154
Change-Id: I43823343721b9e70524ea3f5e8f39dd543a3e92b