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 2022-04-13 21:04:02 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old) and /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1900 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-SQLAlchemy" Wed Apr 13 21:04:02 2022 rev:94 rq:969154 version:1.4.35 Changes: -------- --- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes 2022-03-14 19:37:04.578127097 +0100 +++ /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1900/python-SQLAlchemy.changes 2022-04-13 21:04:05.580523359 +0200 @@ -1,0 +2,158 @@ +Sun Apr 10 17:41:04 UTC 2022 - Arun Persaud <a...@gmx.de> + +- update to version 1.4.35: + * sql + + [sql] [bug] Fixed bug in newly implemented + FunctionElement.table_valued.joins_implicitly feature where the + parameter would not automatically propagate from the original + TableValuedAlias object to the secondary object produced when + calling upon TableValuedAlias.render_derived() or + TableValuedAlias.alias(). + Additionally repaired these issues in TableValuedAlias: + - repaired a potential memory issue which could occur when + repeatedly calling TableValuedAlias.render_derived() against + successive copies of the same object (for .alias(), we + currently have to still continue chaining from the previous + element. not sure if this can be improved but this is standard + behavior for .alias() elsewhere) + - repaired issue where the individual element types would be + lost when calling upon TableValuedAlias.render_derived() or + TableValuedAlias.alias(). + References: #7890 + + [sql] [bug] [regression] Fixed regression caused by #7823 which + impacted the caching system, such that bound parameters that had + been ???cloned??? within ORM operations, such as polymorphic + loading, would in some cases not acquire their correct + execution-time value leading to incorrect bind values being + rendered. References: #7903 + +- changes from version 1.4.34: + * orm + + [orm] [bug] [regression] Fixed regression caused by #7861 where + invoking an Insert construct which contained ORM entities + directly via Session.execute() would fail. References: #7878 + * postgresql + + [postgresql] [bug] Scaled back a fix made for #6581 where + ???executemany values??? mode for psycopg2 were disabled for all ???ON + CONFLICT??? styles of INSERT, to not apply to the ???ON CONFLICT DO + NOTHING??? clause, which does not include any parameters and is + safe for ???executemany values??? mode. ???ON CONFLICT DO UPDATE??? is + still blocked from ???executemany values??? as there may be + additional parameters in the DO UPDATE clause that cannot be + batched (which is the original issue fixed by #6581). + References: #7880 + +- changes from version 1.4.33: + * orm + + [orm] [usecase] Added with_polymorphic.adapt_on_names to the + with_polymorphic() function, which allows a polymorphic load + (typically with concrete mapping) to be stated against an + alternative selectable that will adapt to the original mapped + selectable on column names alone. References: #7805 + + [orm] [usecase] Added new attributes + UpdateBase.returning_column_descriptions and + UpdateBase.entity_description to allow for inspection of ORM + attributes and entities that are installed as part of an Insert, + Update, or Delete construct. The Select.column_descriptions + accessor is also now implemented for Core-only selectables. + References: #7861 + + [orm] [bug] [regression] Fixed regression in ???dynamic??? loader + strategy where the Query.filter_by() method would not be given + an appropriate entity to filter from, in the case where a + ???secondary??? table were present in the relationship being queried + and the mapping were against something complex such as a ???with + polymorphic???. References: #7868 + + [orm] [bug] Fixed bug where composite() attributes would not + work in conjunction with the selectin_polymorphic() loader + strategy for joined table inheritance. References: #7801 + + [orm] [bug] [performance] Improvements in memory usage by the + ORM, removing a significant set of intermediary expression + objects that are typically stored when a copy of an expression + object is created. These clones have been greatly reduced, + reducing the number of total expression objects stored in memory + by ORM mappings by about 30%. References: #7823 + + [orm] [bug] Fixed issue where the selectin_polymorphic() loader + option would not work with joined inheritance mappers that don???t + have a fixed ???polymorphic_on??? column. Additionally added test + support for a wider variety of usage patterns with this + construct. References: #7799 + + [orm] [bug] Fixed bug in with_loader_criteria() function where + loader criteria would not be applied to a joined eager load that + were invoked within the scope of a refresh operation for the + parent object. References: #7862 + + [orm] [bug] Fixed issue where the Mapper would reduce a + user-defined Mapper.primary_key argument too aggressively, in + the case of mapping to a UNION where for some of the SELECT + entries, two columns are essentially equivalent, but in another, + they are not, such as in a recursive CTE. The logic here has + been changed to accept a given user-defined PK as given, where + columns will be related to the mapped selectable but no longer + ???reduced??? as this heuristic can???t accommodate for all + situations. References: #7842 + * engine + + [engine] [usecase] Added new parameter Engine.dispose.close, + defaulting to True. When False, the engine disposal does not + touch the connections in the old pool at all, simply dropping + the pool and replacing it. This use case is so that when the + original pool is transferred from a parent process, the parent + process may continue to use those connections. + See also + Using Connection Pools with Multiprocessing or os.fork() - revised documentation + References: #7815, #7877 + + [engine] [bug] Further clarified connection-level logging to + indicate the BEGIN, ROLLBACK and COMMIT log messages do not + actually indicate a real transaction when the AUTOCOMMIT + isolation level is in use; messaging has been extended to + include the BEGIN message itself, and the messaging has also + been fixed to accommodate when the Engine level + create_engine.isolation_level parameter was used directly. + References: #7853 + * sql + + [sql] [usecase] Added new parameter + FunctionElement.table_valued.joins_implicitly, for the + FunctionElement.table_valued() construct. This parameter + indicates that the given table-valued function implicitly joins + to the table it refers towards, essentially disabling the ???from + linting??? feature, i.e. the ???cartesian product??? warning, from + taking effect due to the presence of this parameter. May be used + for functions such as func.json_each(). References: #7845 + + [sql] [bug] The bindparam.literal_execute parameter now takes + part of the cache generation of a bindparam(), since it changes + the sql string generated by the compiler. Previously the correct + bind values were used, but the literal_execute would be ignored + on subsequent executions of the same query. References: #7876 + + [sql] [bug] [regression] Fixed regression caused by #7760 where + the new capabilities of TextualSelect were not fully implemented + within the compiler properly, leading to issues with composed + INSERT constructs such as ???INSERT FROM SELECT??? and ???INSERT???ON + CONFLICT??? when combined with CTE and textual statements. + References: #7798 + * schema + + [schema] [usecase] Added support so that the + Table.to_metadata.referred_schema_fn callable passed to + Table.to_metadata() may return the value BLANK_SCHEMA to + indicate that the referenced foreign key should be reset to + None. The RETAIN_SCHEMA symbol may also be returned from this + function to indicate ???no change???, which will behave the same as + None currently does which also indicates no change. References: + #7860 + * sqlite + + [sqlite] [bug] [reflection] Fixed bug where the name of CHECK + constraints under SQLite would not be reflected if the name were + created using quotes, as is the case when the name uses mixed + case or special characters. References: #5463 + * mssql + + [mssql] [bug] [regression] Fixed regression caused by #7160 + where FK reflection in conjunction with a low compatibility + level setting (compatibility level 80: SQL Server 2000) causes + an ???Ambiguous column name??? error. Patch courtesy @Lin-Your. + References: #7812 + * misc + + [bug] [ext] Improved the error message that???s raised for the + case where the association_proxy() construct attempts to access + a target attribute at the class level, and this access + fails. The particular use case here is when proxying to a hybrid + attribute that does not include a working class-level + implementation. References: #7827 + +------------------------------------------------------------------- Old: ---- SQLAlchemy-1.4.32.tar.gz New: ---- SQLAlchemy-1.4.35.tar.gz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ python-SQLAlchemy.spec ++++++ --- /var/tmp/diff_new_pack.rtn5wo/_old 2022-04-13 21:04:06.384524001 +0200 +++ /var/tmp/diff_new_pack.rtn5wo/_new 2022-04-13 21:04:06.388524005 +0200 @@ -20,7 +20,7 @@ %define skip_python2 1 %define oldpython python Name: python-SQLAlchemy -Version: 1.4.32 +Version: 1.4.35 Release: 0 Summary: Database Abstraction Library License: MIT ++++++ SQLAlchemy-1.4.32.tar.gz -> SQLAlchemy-1.4.35.tar.gz ++++++ /work/SRC/openSUSE:Factory/python-SQLAlchemy/SQLAlchemy-1.4.32.tar.gz /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1900/SQLAlchemy-1.4.35.tar.gz differ: char 5, line 1