Hello community,
here is the log from the commit of package python-SQLAlchemy for openSUSE:Factory checked in at 2019-04-28 19:59:41
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old)
and /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.5536 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-SQLAlchemy"
Sun Apr 28 19:59:41 2019 rev:63 rq:696966 version:1.3.3
Changes:
--------
--- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes 2019-04-15 11:50:19.350482519 +0200
+++ /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.5536/python-SQLAlchemy.changes 2019-04-28 19:59:45.426923946 +0200
@@ -1,0 +2,67 @@
+Sun Apr 21 22:00:19 UTC 2019 - Arun Persaud
+
+- update to version 1.3.3:
+ * orm
+ + Fixed 1.3 regression in new “ambiguous FROMs” query logic
+ introduced in Query.join() handles ambiguity in deciding the
+ “left” side more explicitly where a Query that explicitly places
+ an entity in the FROM clause with Query.select_from() and also
+ joins to it using Query.join() would later cause an “ambiguous
+ FROM” error if that entity were used in additional joins, as the
+ entity appears twice in the “from” list of the Query. The fix
+ resolves this ambiguity by folding the standalone entity into
+ the join that it’s already a part of in the same way that
+ ultimately happens when the SELECT statement is rendered.
+ References: #4584
+ + Adjusted the Query.filter_by() method to not call and()
+ internally against multiple criteria, instead passing it off to
+ Query.filter() as a series of criteria, instead of a single
+ criteria. This allows Query.filter_by() to defer to
+ Query.filter()’s treatment of variable numbers of clauses,
+ including the case where the list is empty. In this case, the
+ Query object will not have a .whereclause, which allows
+ subsequent “no whereclause” methods like Query.select_from() to
+ behave consistently. References: #4606
+ * postgresql
+ + Fixed regression from release 1.3.2 caused by #4562 where a URL
+ that contained only a query string and no hostname, such as for
+ the purposes of specifying a service file with connection
+ information, would no longer be propagated to psycopg2
+ properly. The change in #4562 has been adjusted to further suit
+ psycopg2’s exact requirements, which is that if there are any
+ connection parameters whatsoever, the “dsn” parameter is no
+ longer required, so in this case the query string parameters are
+ passed alone. References: #4601
+ * mssql
+ + Fixed issue in SQL Server dialect where if a bound parameter
+ were present in an ORDER BY expression that would ultimately not
+ be rendered in the SQL Server version of the statement, the
+ parameters would still be part of the execution parameters,
+ leading to DBAPI-level errors. Pull request courtesy Matt
+ Lewellyn. References: #4587
+ * misc
+ + Fixed behavioral regression as a result of deprecating the
+ “use_threadlocal” flag for Pool, where the SingletonThreadPool
+ no longer makes use of this option which causes the “rollback on
+ return” logic to take place when the same Engine is used
+ multiple times in the context of a transaction to connect or
+ implicitly execute, thereby cancelling the transaction. While
+ this is not the recommended way to work with engines and
+ connections, it is nonetheless a confusing behavioral change as
+ when using SingletonThreadPool, the transaction should stay open
+ regardless of what else is done with the same engine in the same
+ thread. The use_threadlocal flag remains deprecated however the
+ SingletonThreadPool now implements its own version of the same
+ logic. References: #4585
+ + Fixed bug where using copy.copy() or copy.deepcopy() on
+ MutableList would cause the items within the list to be
+ duplicated, due to an inconsistency in how Python pickle and
+ copy both make use of __getstate__() and __setstate__()
+ regarding lists. In order to resolve, a __reduce_ex__ method had
+ to be added to MutableList. In order to maintain backwards
+ compatibility with existing pickles based on __getstate__(), the
+ __setstate__() method remains as well; the test suite asserts
+ that pickles made against the old version of the class can still
+ be deserialized by the pickle module. References: #4603
+
+-------------------------------------------------------------------
Old:
----
SQLAlchemy-1.3.2.tar.gz
New:
----
SQLAlchemy-1.3.3.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python-SQLAlchemy.spec ++++++
--- /var/tmp/diff_new_pack.AtNJB3/_old 2019-04-28 19:59:46.786923126 +0200
+++ /var/tmp/diff_new_pack.AtNJB3/_new 2019-04-28 19:59:46.790923124 +0200
@@ -19,7 +19,7 @@
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
%define oldpython python
Name: python-SQLAlchemy
-Version: 1.3.2
+Version: 1.3.3
Release: 0
Summary: Database Abstraction Library
License: MIT
++++++ SQLAlchemy-1.3.2.tar.gz -> SQLAlchemy-1.3.3.tar.gz ++++++
++++ 8324 lines of diff (skipped)