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 2021-07-29 21:31:07
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old)
and /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1899 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-SQLAlchemy"
Thu Jul 29 21:31:07 2021 rev:87 rq:908428 version:1.4.22
Changes:
--------
--- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes
2021-07-16 22:13:02.926700207 +0200
+++
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1899/python-SQLAlchemy.changes
2021-07-29 21:31:39.632793486 +0200
@@ -1,0 +2,145 @@
+Thu Jul 22 01:35:15 UTC 2021 - Arun Persaud <[email protected]>
+
+- update to version 1.4.22:
+ * orm
+ + Fixed issue in new Table.table_valued() method where the
+ resulting TableValuedColumn construct would not respond
+ correctly to alias adaptation as is used throughout the ORM,
+ such as for eager loading, polymorphic loading, etc.
+ + Fixed issue where usage of the Result.unique() method with an
+ ORM result that included column expressions with unhashable
+ types, such as JSON or ARRAY using non-tuples would silently
+ fall back to using the id() function, rather than raising an
+ error. This now raises an error when the Result.unique() method
+ is used in a 2.0 style ORM query. Additionally, hashability is
+ assumed to be True for result values of unknown type, such as
+ often happens when using SQL functions of unknown return type;
+ if values are truly not hashable then the hash() itself will
+ raise.
+ + For legacy ORM queries, since the legacy Query object uniquifies
+ in all cases, the old rules remain in place, which is to use
+ id() for result values of unknown type as this legacy uniquing
+ is mostly for the purpose of uniquing ORM entities and not
+ column values.
+ + Fixed an issue where clearing of mappers during things like test
+ suite teardowns could cause a ???dictionary changed size??? warning
+ during garbage collection, due to iteration of a
+ weak-referencing dictionary. A list() has been applied to
+ prevent concurrent GC from affecting this operation.
+ + Fixed critical caching issue where the ORM???s persistence feature
+ using INSERT..RETURNING would cache an incorrect query when
+ mixing the ???bulk save??? and standard ???flush??? forms of INSERT.
+ * engine
+ + Added some guards against KeyError in the event system to
+ accommodate the case that the interpreter is shutting down at
+ the same time Engine.dispose() is being called, which would
+ cause stack trace warnings.
+ * sql
+ + Fixed issue where use of the case.whens parameter passing a
+ dictionary positionally and not as a keyword argument would emit
+ a 2.0 deprecation warning, referring to the deprecation of
+ passing a list positionally. The dictionary format of ???whens???,
+ passed positionally, is still supported and was accidentally
+ marked as deprecated.
+ + Fixed issue where type-specific bound parameter handlers would
+ not be called upon in the case of using the Insert.values()
+ method with the Python None value; in particular, this would be
+ noticed when using the JSON datatype as well as related
+ PostgreSQL specific types such as JSONB which would fail to
+ encode the Python None value into JSON null, however the issue
+ was generalized to any bound parameter handler in conjunction
+ with this specific method of Insert.
+
+- changes from version 1.4.21:
+ * orm
+ + Modified the approach used for history tracking of scalar object
+ relationships that are not many-to-one, i.e. one-to-one
+ relationships that would otherwise be one-to-many. When
+ replacing a one-to-one value, the ???old??? value that would be
+ replaced is no longer loaded immediately, and is instead handled
+ during the flush process. This eliminates an historically
+ troublesome lazy load that otherwise often occurs when assigning
+ to a one-to-one attribute, and is particularly troublesome when
+ using ???lazy=???raise?????? as well as asyncio use cases.
+ + This change does cause a behavioral change within the
+ AttributeEvents.set() event, which is nonetheless currently
+ documented, which is that the event applied to such a one-to-one
+ attribute will no longer receive the ???old??? parameter if it is
+ unloaded and the relationship.active_history flag is not set. As
+ is documented in AttributeEvents.set(), if the event handler
+ needs to receive the ???old??? value when the event fires off, the
+ active_history flag must be established either with the event
+ listener or with the relationship. This is already the behavior
+ with other kinds of attributes such as many-to-one and column
+ value references.
+ + The change additionally will defer updating a backref on the
+ ???old??? value in the less common case that the ???old??? value is
+ locally present in the session, but isn???t loaded on the
+ relationship in question, until the next flush occurs. If this
+ causes an issue, again the normal relationship.active_history
+ flag can be set to True on the relationship.
+ + Fixed regression caused in 1.4.19 due to #6503 and related
+ involving Query.with_entities() where the new structure used
+ would be inappropriately transferred to an enclosing Query when
+ making use of set operations such as Query.union(), causing the
+ JOIN instructions within to be applied to the outside query as
+ well.
+ + Fixed regression which appeared in version 1.4.3 due to #6060
+ where rules that limit ORM adaptation of derived selectables
+ interfered with other ORM-adaptation based cases, in this case
+ when applying adaptations for a with_polymorphic() against a
+ mapping which uses a column_property() which in turn makes use
+ of a scalar select that includes a aliased() object of the
+ mapped table.
+ + Fixed ORM regression where ad-hoc label names generated for
+ hybrid properties and potentially other similar types of
+ ORM-enabled expressions would usually be propagated outwards
+ through subqueries, allowing the name to be retained in the
+ final keys of the result set even when selecting from
+ subqueries. Additional state is now tracked in this case that
+ isn???t lost when a hybrid is selected out of a Core select /
+ subquery.
+ * sql
+ + Added new method HasCTE.add_cte() to each of the select(),
+ insert(), update() and delete() constructs. This method will add
+ the given CTE as an ???independent??? CTE of the statement, meaning
+ it renders in the WITH clause above the statement
+ unconditionally even if it is not otherwise referenced in the
+ primary statement. This is a popular use case on the PostgreSQL
+ database where a CTE is used for a DML statement that runs
+ against database rows independently of the primary statement.
+ + Fixed issue in CTE constructs where a recursive CTE that
+ referred to a SELECT that has duplicate column names, which are
+ typically deduplicated using labeling logic in 1.4, would fail
+ to refer to the deduplicated label name correctly within the
+ WITH clause.
+ + Fixed regression where the tablesample() construct would fail to
+ be executable when constructed given a floating-point sampling
+ value not embedded within a SQL function.
+ * postgresql
+ + Fixed issue in Insert.on_conflict_do_nothing() and
+ Insert.on_conflict_do_update() where the name of a unique
+ constraint passed as the constraint parameter would not be
+ properly truncated for length if it were based on a naming
+ convention that generated a too-long name for the PostgreSQL max
+ identifier length of 63 characters, in the same way which occurs
+ within a CREATE TABLE statement.
+ + Fixed issue where the PostgreSQL ENUM datatype as embedded in
+ the ARRAY datatype would fail to emit correctly in create/drop
+ when the schema_translate_map feature were also in
+ use. Additionally repairs a related issue where the same
+ schema_translate_map feature would not work for the ENUM
+ datatype in combination with a CAST, that???s also intrinsic to
+ how the ARRAY(ENUM) combination works on the PostgreSQL dialect.
+ + Fixed issue in Insert.on_conflict_do_nothing() and
+ Insert.on_conflict_do_update() where the name of a unique
+ constraint passed as the constraint parameter would not be
+ properly quoted if it contained characters which required
+ quoting.
+ * mssql
+ + Fixed regression where the special dotted-schema name handling
+ for the SQL Server dialect would not function correctly if the
+ dotted schema name were used within the schema_translate_map
+ feature.
+
+-------------------------------------------------------------------
Old:
----
SQLAlchemy-1.4.20.tar.gz
New:
----
SQLAlchemy-1.4.22.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python-SQLAlchemy.spec ++++++
--- /var/tmp/diff_new_pack.hCSEFD/_old 2021-07-29 21:31:40.224792757 +0200
+++ /var/tmp/diff_new_pack.hCSEFD/_new 2021-07-29 21:31:40.228792752 +0200
@@ -20,7 +20,7 @@
%define skip_python2 1
%define oldpython python
Name: python-SQLAlchemy
-Version: 1.4.20
+Version: 1.4.22
Release: 0
Summary: Database Abstraction Library
License: MIT
++++++ SQLAlchemy-1.4.20.tar.gz -> SQLAlchemy-1.4.22.tar.gz ++++++
/work/SRC/openSUSE:Factory/python-SQLAlchemy/SQLAlchemy-1.4.20.tar.gz
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1899/SQLAlchemy-1.4.22.tar.gz
differ: char 5, line 1
