Hello community,
here is the log from the commit of package python-SQLAlchemy for
openSUSE:Factory checked in at 2019-07-28 10:18:43
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old)
and /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.4126 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-SQLAlchemy"
Sun Jul 28 10:18:43 2019 rev:66 rq:717942 version:1.3.6
Changes:
--------
--- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes
2019-06-30 10:14:09.650935783 +0200
+++
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.4126/python-SQLAlchemy.changes
2019-07-28 10:18:48.216601518 +0200
@@ -1,0 +2,110 @@
+Mon Jul 22 16:08:19 UTC 2019 - Todd R <[email protected]>
+
+- update to version 1.3.6
+ + orm
+ * [feature] Added new loader option method Load.options()
+ which allows loader options to be constructed hierarchically,
+ so that many sub-options can be applied to a particular path
+ without needing to call defaultload() many times.
+ * [bug] Fixed regression caused by #4365 where a join from an
+ entity to itself without using aliases no longer raises an
+ informative error message, instead failing on an assertion.
+ The informative error condition has been restored.
+ * [bug] Fixed an issue where the orm._ORMJoin.join() method,
+ which is a not-internally-used ORM-level method that exposes
+ what is normally an internal process of Query.join(), did
+ not propagate the full and outerjoin keyword arguments
+ correctly.
+ * [bug] Fixed bug where a many-to-one relationship that
+ specified uselist=True would fail to update correctly during
+ a primary key change where a related column needs to change.
+ * [bug] Fixed bug where the detection for many-to-one or
+ one-to-one use with a “dynamic” relationship, which is an
+ invalid configuration, would fail to raise if the
+ relationship were configured with uselist=True. The current
+ fix is that it warns, instead of raises, as this would
+ otherwise be backwards incompatible, however in a future
+ release it will be a raise.
+ * [bug] Fixed bug where a synonym created against a mapped
+ attribute that does not exist yet, as is the case when it
+ refers to backref before mappers are configured, would raise
+ recursion errors when trying to test for attributes on it
+ which ultimately don’t exist (as occurs when the classes are
+ run through Sphinx autodoc), as the unconfigured state of
+ the synonym would put it into an attribute not found loop.
+ * [performance] The optimzation applied to selectin loading
+ in #4340 where a JOIN is not needed to eagerly load related
+ items is now applied to many-to-one relationships as well,
+ so that only the related table is queried for a simple join
+ condition. In this case, the related items are queried based
+ on the value of a foreign key column on the parent; if these
+ columns are deferred or otherwise not loaded on any of the
+ parent objects in the collection, the loader falls back to the
+ JOIN method.
+ + engine
+ * [bug] Fixed bug where using reflection function such as
+ MetaData.reflect() with an Engine object that had execution
+ options applied to it would fail, as the resulting
+ OptionEngine proxy object failed to include a .engine
+ attribute used within the reflection routines.
+ + sql
+ * [bug] Adjusted the initialization for Enum to minimize how
+ often it invokes the .__members__ attribute of a given
+ PEP-435 enumeration object, to suit the case where this
+ attribute is expensive to invoke, as is the case for some
+ popular third party enumeration libraries.
+ * [bug] [postgresql] Fixed issue where the array_agg construct
+ in combination with FunctionElement.filter() would not
+ produce the correct operator precedence in combination
+ with the array index operator.
+ * [bug] Fixed an unlikely issue where the “corresponding
+ column” routine for unions and other CompoundSelect objects
+ could return the wrong column in some overlapping column
+ situtations, thus potentially impacting some ORM operations
+ when set operations are in use, if the underlying select()
+ constructs were used previously in other similar kinds of
+ routines, due to a cached value not being cleared.
+ + postgresql
+ * [usecase] Added support for reflection of indexes on
+ PostgreSQL partitioned tables, which was added to PostgreSQL
+ as of version 11.
+ * [usecase] Added support for multidimensional Postgresql array
+ literals via nesting the postgresql.array object within
+ another one. The multidimensional array type is detected
+ automatically.
+ + mysql
+ * [bug] Fixed bug where the special logic to render “NULL” for
+ the TIMESTAMP datatype when nullable=True would not work if the
+ column’s datatype were a TypeDecorator or a Variant. The logic
+ now ensures that it unwraps down to the original TIMESTAMP so
+ that this special case NULL keyword is correctly rendered when
+ requested.
+ * [bug] Enhanced MySQL/MariaDB version string parsing to
+ accommodate for exotic MariaDB version strings where the
+ “MariaDB” word is embedded among other alphanumeric
+ characters such as “MariaDBV1”. This detection is critical
+ in order to correctly accommodate for API features that have
+ split between MySQL and MariaDB such as the
+ “transaction_isolation” system variable.
+ + sqlite
+ * [usecase] Added support for composite (tuple) IN operators
+ with SQLite, by rendering the VALUES keyword for this backend.
+ As other backends such as DB2 are known to use the same syntax,
+ the syntax is enabled in the base compiler using a dialect-level
+ flag tuple_in_values. The change also includes support for
+ “empty IN tuple” expressions for SQLite when using “in_()”
+ between a tuple value and an empty set.
+ + mssql
+ * [bug] Ensured that the queries used to reflect indexes and
+ view definitions will explicitly CAST string parameters into
+ NVARCHAR, as many SQL Server drivers frequently treat string
+ values, particularly those with non-ascii characters or
+ larger string values, as TEXT which often don’t compare
+ correctly against VARCHAR characters in SQL Server’s
+ information schema tables for some reason. These CAST
+ operations already take place for reflection queries against
+ SQL Server information_schema. tables but were missing from
+ three additional queries that are against sys.tables.
+
+
+-------------------------------------------------------------------
Old:
----
SQLAlchemy-1.3.5.tar.gz
New:
----
SQLAlchemy-1.3.6.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python-SQLAlchemy.spec ++++++
--- /var/tmp/diff_new_pack.Bupwda/_old 2019-07-28 10:18:49.052601519 +0200
+++ /var/tmp/diff_new_pack.Bupwda/_new 2019-07-28 10:18:49.052601519 +0200
@@ -19,7 +19,7 @@
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
%define oldpython python
Name: python-SQLAlchemy
-Version: 1.3.5
+Version: 1.3.6
Release: 0
Summary: Database Abstraction Library
License: MIT
++++++ SQLAlchemy-1.3.5.tar.gz -> SQLAlchemy-1.3.6.tar.gz ++++++
++++ 16813 lines of diff (skipped)
