Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package python-SQLAlchemy for
openSUSE:Factory checked in at 2022-08-18 16:48:46
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old)
and /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.2083 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-SQLAlchemy"
Thu Aug 18 16:48:46 2022 rev:99 rq:997497 version:1.4.40
Changes:
--------
--- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes
2022-07-12 11:12:06.059671869 +0200
+++
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.2083/python-SQLAlchemy.changes
2022-08-18 16:48:56.393414145 +0200
@@ -1,0 +2,114 @@
+Wed Aug 17 03:06:32 UTC 2022 - Arun Persaud <[email protected]>
+
+- 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
+
+-------------------------------------------------------------------
Old:
----
SQLAlchemy-1.4.39.tar.gz
New:
----
SQLAlchemy-1.4.40.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python-SQLAlchemy.spec ++++++
--- /var/tmp/diff_new_pack.YYf9Ui/_old 2022-08-18 16:48:56.945415430 +0200
+++ /var/tmp/diff_new_pack.YYf9Ui/_new 2022-08-18 16:48:56.953415448 +0200
@@ -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
++++++ SQLAlchemy-1.4.39.tar.gz -> SQLAlchemy-1.4.40.tar.gz ++++++
/work/SRC/openSUSE:Factory/python-SQLAlchemy/SQLAlchemy-1.4.39.tar.gz
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.2083/SQLAlchemy-1.4.40.tar.gz
differ: char 5, line 1
