Hello community,

here is the log from the commit of package python-SQLAlchemy for 
openSUSE:Factory checked in at 2019-09-07 12:30:52
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old)
 and      /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.7948 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "python-SQLAlchemy"

Sat Sep  7 12:30:52 2019 rev:69 rq:727458 version:1.3.8

Changes:
--------
--- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes      
2019-08-27 10:11:36.563978637 +0200
+++ 
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.7948/python-SQLAlchemy.changes
    2019-09-07 12:30:55.953691456 +0200
@@ -1,0 +2,77 @@
+Sat Aug 31 04:34:30 UTC 2019 - Arun Persaud <[email protected]>
+
+- update to version 1.3.8:
+  * orm
+    + Fixed bug where Load objects were not pickleable due to
+      mapper/relationship state in the internal context
+      dictionary. These objects are now converted to picklable using
+      similar techniques as that of other elements within the loader
+      option system that have long been serializable.  References:
+      #4823
+    + Added support for the use of an Enum datatype using Python
+      pep-435 enumeration objects as values for use as a primary key
+      column mapped by the ORM. As these values are not inherently
+      sortable, as required by the ORM for primary keys, a new
+      TypeEngine.sort_key_function attribute is added to the typing
+      system which allows any SQL type to implement a sorting for
+      Python objects of its type which is consulted by the unit of
+      work. The Enum type then defines this using the database value
+      of a given enumeration. The sorting scheme can be also be
+      redefined by passing a callable to the Enum.sort_key_function
+      parameter. Pull request courtesy Nicolas Caniart.  References:
+      #4285
+  * engine
+    + Added new parameter create_engine.hide_parameters which when set
+      to True will cause SQL parameters to no longer be logged, nor
+      rendered in the string representation of a StatementError
+      object.  References: #4815
+    + Fixed an issue whereby if the dialect “initialize” process which
+      occurs on first connect would encounter an unexpected exception,
+      the initialize process would fail to complete and then no longer
+      attempt on subsequent connection attempts, leaving the dialect
+      in an un-initialized, or partially initialized state, within the
+      scope of parameters that need to be established based on
+      inspection of a live connection. The “invoke once” logic in the
+      event system has been reworked to accommodate for this
+      occurrence using new, private API features that establish an
+      “exec once” hook that will continue to allow the initializer to
+      fire off on subsequent connections, until it completes without
+      raising an exception. This does not impact the behavior of the
+      existing once=True flag within the event system.  References:
+      #4807
+  * postgresql
+    + Revised the approach for the just added support for the psycopg2
+      “execute_values()” feature added in 1.3.7 for #4623. The
+      approach relied upon a regular expression that would fail to
+      match for a more complex INSERT statement such as one which had
+      subqueries involved. The new approach matches exactly the string
+      that was rendered as the VALUES clause.  References: #4623
+    + Fixed bug where Postgresql operators such as
+      postgresql.ARRAY.Comparator.contains() and
+      postgresql.ARRAY.Comparator.contained_by() would fail to
+      function correctly for non-integer values when used against a
+      postgresql.array object, due to an erroneous assert statement.
+      References: #4822
+    + Added support for reflection of CHECK constraints that include
+      the special PostgreSQL qualifier “NOT VALID”, which can be
+      present for CHECK constraints that were added to an exsiting
+      table with the directive that they not be applied to existing
+      data in the table. The PostgreSQL dictionary for CHECK
+      constraints as returned by Inspector.get_check_constraints() may
+      include an additional entry dialect_options which within will
+      contain an entry "not_valid": True if this symbol is
+      detected. Pull request courtesy Bill Finn.  References: #4824
+  * sqlite
+    + Fixed bug where a FOREIGN KEY that was set up to refer to the
+      parent table by table name only without the column names would
+      not correctly be reflected as far as setting up the “referred
+      columns”, since SQLite’s PRAGMA does not report on these columns
+      if they weren’t given explicitly. For some reason this was
+      harcoded to assume the name of the local column, which might
+      work for some cases but is not correct. The new approach
+      reflects the primary key of the referred table and uses the
+      constraint columns list as the referred columns list, if the
+      remote column(s) aren’t present in the reflected pragma
+      directly.  References: #4810
+
+-------------------------------------------------------------------

Old:
----
  SQLAlchemy-1.3.7.tar.gz

New:
----
  SQLAlchemy-1.3.8.tar.gz

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ python-SQLAlchemy.spec ++++++
--- /var/tmp/diff_new_pack.lgIsO9/_old  2019-09-07 12:30:57.449691273 +0200
+++ /var/tmp/diff_new_pack.lgIsO9/_new  2019-09-07 12:30:57.485691268 +0200
@@ -19,7 +19,7 @@
 %{?!python_module:%define python_module() python-%{**} python3-%{**}}
 %define oldpython python
 Name:           python-SQLAlchemy
-Version:        1.3.7
+Version:        1.3.8
 Release:        0
 Summary:        Database Abstraction Library
 License:        MIT

++++++ SQLAlchemy-1.3.7.tar.gz -> SQLAlchemy-1.3.8.tar.gz ++++++
++++ 30574 lines of diff (skipped)


Reply via email to