Accepting request 997460 from home:apersaud:branches:devel:languages:python
update to latest version OBS-URL: https://build.opensuse.org/request/show/997460 OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-SQLAlchemy?expand=0&rev=215
This commit is contained in:
Git OBS Bridge
@@ -1,3 +1,117 @@
|
||||
-------------------------------------------------------------------
|
||||
Wed Aug 17 03:06:32 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||||
|
||||
- update to version 1.4.40:
|
||||
* orm
|
||||
+ [orm] [bug] Fixed issue where referencing a CTE multiple times
|
||||
in conjunction with a polymorphic SELECT could result in
|
||||
multiple “clones” of the same CTE being constructed, which would
|
||||
then trigger these two CTEs as duplicates. To resolve, the two
|
||||
CTEs are deep-compared when this occurs to ensure that they are
|
||||
equivalent, then are treated as equivalent. References: #8357
|
||||
+ [orm] [bug] A select() construct that is passed a sole ‘*’
|
||||
argument for SELECT *, either via string, text(), or
|
||||
literal_column(), will be interpreted as a Core-level SQL
|
||||
statement rather than as an ORM level statement. This is so that
|
||||
the *, when expanded to match any number of columns, will result
|
||||
in all columns returned in the result. the ORM- level
|
||||
interpretation of select() needs to know the names and types of
|
||||
all ORM columns up front which can’t be achieved when '*' is
|
||||
used. If '* is used amongst other expressions simultaneously
|
||||
with an ORM statement, an error is raised as this can’t be
|
||||
interpreted correctly by the ORM. References: #8235
|
||||
* orm declarative
|
||||
+ [orm] [declarative] [bug] Fixed issue where a hierarchy of
|
||||
classes set up as an abstract or mixin declarative classes could
|
||||
not declare standalone columns on a superclass that would then
|
||||
be copied correctly to a declared_attr callable that wanted to
|
||||
make use of them on a descendant class. References: #8190
|
||||
* engine
|
||||
+ [engine] [usecase] Implemented new
|
||||
Connection.execution_options.yield_per execution option for
|
||||
Connection in Core, to mirror that of the same yield_per option
|
||||
available in the ORM. The option sets both the
|
||||
Connection.execution_options.stream_results option at the same
|
||||
time as invoking Result.yield_per(), to provide the most common
|
||||
streaming result configuration which also mirrors that of the
|
||||
ORM use case in its usage pattern. See also: Using Server Side
|
||||
Cursors (a.k.a. stream results) - revised documentation
|
||||
+ [engine] [bug] Fixed bug in 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
|
||||
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
|
||||
Connection.execution_options.stream_results is set.
|
||||
+ [engine] [bug] Added FilterResult.yield_per() so that result
|
||||
implementations such as MappingResult, ScalarResult and
|
||||
AsyncResult have access to this method. References: #8199
|
||||
* sql
|
||||
+ [sql] [bug] Adjusted the SQL compilation for string containment
|
||||
functions .contains(), .startswith(), .endswith() to force the
|
||||
use of the string concatenation operator, rather than relying
|
||||
upon the overload of the addition operator, so that non-standard
|
||||
use of these operators with for example bytestrings still
|
||||
produces string concatenation operators. References: #8253
|
||||
* mypy
|
||||
+ [mypy] [bug] Fixed a crash of the mypy plugin when using a
|
||||
lambda as a Column default. Pull request curtesy of tchapi.
|
||||
References: #8196
|
||||
* asyncio
|
||||
+ [asyncio] [bug] Added asyncio.shield() to the connection and
|
||||
session release process specifically within the __aexit__()
|
||||
context manager exit, when using AsyncConnection or AsyncSession
|
||||
as a context manager that releases the object when the context
|
||||
manager is complete. This appears to help with task cancellation
|
||||
when using alternate concurrency libraries such as anyio, uvloop
|
||||
that otherwise don’t provide an async context for the connection
|
||||
pool to release the connection properly during task
|
||||
cancellation. References: #8145
|
||||
* postgresql
|
||||
+ [postgresql] [bug] Fixed issue in psycopg2 dialect where the
|
||||
“multiple hosts” feature implemented for #4392, where multiple
|
||||
host:port pairs could be passed in the query string as
|
||||
?host=host1:port1&host=host2:port2&host=host3:port3 was not
|
||||
implemented correctly, as it did not propagate the “port”
|
||||
parameter appropriately. Connections that didn’t use a different
|
||||
“port” likely worked without issue, and connections that had
|
||||
“port” for some of the entries may have incorrectly passed on
|
||||
that hostname. The format is now corrected to pass hosts/ports
|
||||
appropriately. As part of this change, maintained support for
|
||||
another multihost style that worked unintentionally, which is
|
||||
comma-separated ?host=h1,h2,h3&port=p1,p2,p3. This format is
|
||||
more consistent with libpq’s query-string format, whereas the
|
||||
previous format is inspired by a different aspect of libpq’s URI
|
||||
format but is not quite the same thing. If the two styles are
|
||||
mixed together, an error is raised as this is ambiguous.
|
||||
References: #4392
|
||||
* mssql
|
||||
+ [mssql] [bug] Fixed issues that prevented the new usage patterns
|
||||
for using DML with ORM objects presented at Using INSERT, UPDATE
|
||||
and ON CONFLICT (i.e. upsert) to return ORM Objects from working
|
||||
correctly with the SQL Server pyodbc dialect. References: #8210
|
||||
+ [mssql] [bug] Fixed issue where the SQL Server dialect’s query
|
||||
for the current isolation level would fail on Azure Synapse
|
||||
Analytics, due to the way in which this database handles
|
||||
transaction rollbacks after an error has occurred. The initial
|
||||
query has been modified to no longer rely upon catching an error
|
||||
when attempting to detect the appropriate system
|
||||
view. Additionally, to better support this database’s very
|
||||
specific “rollback” behavior, implemented new parameter
|
||||
ignore_no_transaction_on_rollback indicating that a rollback
|
||||
should ignore Azure Synapse error ‘No corresponding transaction
|
||||
found. (111214)’, which is raised if no transaction is present
|
||||
in conflict with the Python DBAPI. Initial patch and valuable
|
||||
debugging assistance courtesy of @ww2406. See also: Avoiding
|
||||
transaction-related exceptions on Azure Synapse Analytics
|
||||
References: #8231
|
||||
* misc
|
||||
+ [bug] [types] Fixed issue where TypeDecorator would not
|
||||
correctly proxy the __getitem__() operator when decorating the
|
||||
ARRAY datatype, without explicit workarounds. References: #7249
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Sat Jul 9 14:12:13 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user