forked from pool/python-SQLAlchemy
- update to version 1.3.12:
* [orm] [bug] Fixed issue involving lazy="raise" strategy where an ORM delete of an object would raise for a simple “use-get” style many-to-one relationship that had lazy=”raise” configured. This is inconsistent vs. the change introduced in 1.3 as part of #4353, where it was established that a history operation that does not expect emit SQL should bypass the lazy="raise" check, and instead effectively treat it as lazy="raise_on_sql" for this case. The fix adjusts the lazy loader strategy to not raise for the case where the lazy load was instructed that it should not emit SQL if the object were not present. * [orm] [bug] Fixed regression introduced in 1.3.0 related to the association proxy refactor in #4351 that prevented composite() attributes from working in terms of an association proxy that references them. * [orm] [bug] Setting persistence-related flags on relationship() while also setting viewonly=True will now emit a regular warning, as these flags do not make sense for a viewonly=True relationship. In particular, the “cascade” settings have their own warning that is generated based on the individual values, such as “delete, delete-orphan”, that should not apply to a viewonly relationship. Note however that in the case of “cascade”, these settings are still erroneously taking effect even though the relationship is set up as “viewonly”. In 1.4, all persistence-related cascade settings will be disallowed on a viewonly=True relationship in order to resolve this issue. * [orm] [bug] [py3k] Fixed issue where when assigning a collection to itself as a slice, the mutation operation would fail as it would first erase the assigned collection inadvertently. As an assignment that does not change the contents should not generate events, the operation is now a no-op. Note that the fix only applies to Python 3; in Python 2, the __setitem__ hook isn’t called in this case; __setslice__ is used instead which recreates the list item-by-item in all cases. * [orm] [bug] Fixed issue where by if the “begin” of a transaction failed at the Core engine/connection level, such as due to network error or database is OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-SQLAlchemy?expand=0&rev=158
This commit is contained in:
@@ -1,3 +0,0 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:afa5541e9dea8ad0014251bc9d56171ca3d8b130c9627c6cb3681cff30be3f8a
|
||||
size 6007784
|
||||
3
SQLAlchemy-1.3.12.tar.gz
Normal file
3
SQLAlchemy-1.3.12.tar.gz
Normal file
@@ -0,0 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:bfb8f464a5000b567ac1d350b9090cf081180ec1ab4aa87e7bca12dab25320ec
|
||||
size 6020509
|
||||
@@ -1,3 +1,58 @@
|
||||
-------------------------------------------------------------------
|
||||
Fri Dec 20 18:45:14 UTC 2019 - Dirk Mueller <dmueller@suse.com>
|
||||
|
||||
- update to version 1.3.12:
|
||||
* [orm] [bug] Fixed issue involving lazy="raise" strategy where an ORM delete
|
||||
of an object would raise for a simple “use-get” style many-to-one relationship
|
||||
that had lazy=”raise” configured. This is inconsistent vs. the change
|
||||
introduced in 1.3 as part of #4353, where it was established that a history
|
||||
operation that does not expect emit SQL should bypass the lazy="raise" check,
|
||||
and instead effectively treat it as lazy="raise_on_sql" for this case. The fix
|
||||
adjusts the lazy loader strategy to not raise for the case where the lazy load
|
||||
was instructed that it should not emit SQL if the object were not present.
|
||||
|
||||
* [orm] [bug] Fixed regression introduced in 1.3.0 related to the association
|
||||
proxy refactor in #4351 that prevented composite() attributes from working in
|
||||
terms of an association proxy that references them.
|
||||
|
||||
* [orm] [bug] Setting persistence-related flags on relationship() while also
|
||||
setting viewonly=True will now emit a regular warning, as these flags do not
|
||||
make sense for a viewonly=True relationship. In particular, the “cascade”
|
||||
settings have their own warning that is generated based on the individual
|
||||
values, such as “delete, delete-orphan”, that should not apply to a viewonly
|
||||
relationship. Note however that in the case of “cascade”, these settings are
|
||||
still erroneously taking effect even though the relationship is set up as
|
||||
“viewonly”. In 1.4, all persistence-related cascade settings will be disallowed
|
||||
on a viewonly=True relationship in order to resolve this issue.
|
||||
|
||||
* [orm] [bug] [py3k] Fixed issue where when assigning a collection to itself
|
||||
as a slice, the mutation operation would fail as it would first erase the
|
||||
assigned collection inadvertently. As an assignment that does not change the
|
||||
contents should not generate events, the operation is now a no-op. Note that
|
||||
the fix only applies to Python 3; in Python 2, the __setitem__ hook isn’t
|
||||
called in this case; __setslice__ is used instead which recreates the list
|
||||
item-by-item in all cases.
|
||||
|
||||
* [orm] [bug] Fixed issue where by if the “begin” of a transaction failed at
|
||||
the Core engine/connection level, such as due to network error or database is
|
||||
locked for some transactional recipes, within the context of the Session
|
||||
procuring that connection from the conneciton pool and then immediately
|
||||
returning it, the ORM Session would not close the connection despite this
|
||||
connection not being stored within the state of that Session. This would lead
|
||||
to the connection being cleaned out by the connection pool weakref handler
|
||||
within garbage collection which is an unpreferred codepath that in some special
|
||||
configurations can emit errors in standard error.
|
||||
|
||||
* sql [sql] [bug] Fixed bug where “distinct” keyword passed to select() would
|
||||
not treat a string value as a “label reference” in the same way that the
|
||||
select.distinct() does; it would instead raise unconditionally. This keyword
|
||||
argument and the others passed to select() will ultimately be deprecated for
|
||||
SQLAlchemy 2.0.
|
||||
|
||||
* [sql] [bug] Changed the text of the exception for “Can’t resolve label
|
||||
reference” to include other kinds of label coercions, namely that “DISTINCT” is
|
||||
also in this category under the PostgreSQL dialect.
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Sat Nov 16 16:33:38 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
#
|
||||
# spec file for package python-SQLAlchemy
|
||||
#
|
||||
# Copyright (c) 2019 SUSE LINUX GmbH, Nuernberg, Germany.
|
||||
# Copyright (c) 2019 SUSE LLC
|
||||
#
|
||||
# All modifications and additions to the file contributed by third parties
|
||||
# remain the property of their copyright owners, unless otherwise agreed
|
||||
@@ -19,7 +19,7 @@
|
||||
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
|
||||
%define oldpython python
|
||||
Name: python-SQLAlchemy
|
||||
Version: 1.3.11
|
||||
Version: 1.3.12
|
||||
Release: 0
|
||||
Summary: Database Abstraction Library
|
||||
License: MIT
|
||||
|
||||
Reference in New Issue
Block a user