diff --git a/SQLAlchemy-1.4.39.tar.gz b/SQLAlchemy-1.4.39.tar.gz deleted file mode 100644 index 143a70b..0000000 --- a/SQLAlchemy-1.4.39.tar.gz +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:8194896038753b46b08a0b0ae89a5d80c897fb601dd51e243ed5720f1f155d27 -size 8212369 diff --git a/SQLAlchemy-1.4.40.tar.gz b/SQLAlchemy-1.4.40.tar.gz new file mode 100644 index 0000000..c19bb01 --- /dev/null +++ b/SQLAlchemy-1.4.40.tar.gz @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:44a660506080cc975e1dfa5776fe5f6315ddc626a77b50bf0eee18b0389ea265 +size 8277132 diff --git a/python-SQLAlchemy.changes b/python-SQLAlchemy.changes index 7b5c380..829e31d 100644 --- a/python-SQLAlchemy.changes +++ b/python-SQLAlchemy.changes @@ -1,3 +1,117 @@ +------------------------------------------------------------------- +Wed Aug 17 03:06:32 UTC 2022 - Arun Persaud + +- 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 diff --git a/python-SQLAlchemy.spec b/python-SQLAlchemy.spec index e9ab024..89f38df 100644 --- a/python-SQLAlchemy.spec +++ b/python-SQLAlchemy.spec @@ -20,7 +20,7 @@ %define skip_python2 1 %define oldpython python Name: python-SQLAlchemy -Version: 1.4.39 +Version: 1.4.40 Release: 0 Summary: Database Abstraction Library License: MIT