{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.hZmd2hmG/b1/sqlalchemy_2.0.32+ds1-1_arm64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.hZmd2hmG/b2/sqlalchemy_2.0.32+ds1-1_arm64.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,5 +1,5 @@\n \n- 92a8207bd406ea6970ca421807227985 3956228 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb\n+ d98302d7d10e67aea004361af01138c4 3956204 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb\n b697fb08b62adad70514c341f58b75f1 886308 debug optional python3-sqlalchemy-ext-dbgsym_2.0.32+ds1-1_arm64.deb\n d08c0cf1c4bb6b8e5595ba47690a2212 123356 python optional python3-sqlalchemy-ext_2.0.32+ds1-1_arm64.deb\n 0955e7f12a0b73c1ab8406c88fbab7d2 1196068 python optional python3-sqlalchemy_2.0.32+ds1-1_all.deb\n"}, {"source1": "python-sqlalchemy-doc_2.0.32+ds1-1_all.deb", "source2": "python-sqlalchemy-doc_2.0.32+ds1-1_all.deb", "unified_diff": null, "details": [{"source1": "file list", "source2": "file list", "unified_diff": "@@ -1,3 +1,3 @@\n -rw-r--r-- 0 0 0 4 2024-08-23 07:52:58.000000 debian-binary\n -rw-r--r-- 0 0 0 13928 2024-08-23 07:52:58.000000 control.tar.xz\n--rw-r--r-- 0 0 0 3942108 2024-08-23 07:52:58.000000 data.tar.xz\n+-rw-r--r-- 0 0 0 3942084 2024-08-23 07:52:58.000000 data.tar.xz\n"}, {"source1": "control.tar.xz", "source2": "control.tar.xz", "unified_diff": null, "details": [{"source1": "control.tar", "source2": "control.tar", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "comments": ["Files differ"], "unified_diff": null}]}]}]}, {"source1": "data.tar.xz", "source2": "data.tar.xz", "unified_diff": null, "details": [{"source1": "data.tar", "source2": "data.tar", "unified_diff": null, "details": [{"source1": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_10.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_10.html", "unified_diff": "@@ -592,15 +592,15 @@\n Fixed performance regression caused by the fix for #3937 where\n+ Fixed performance regression caused by the fix for #3937 where\n cx_Oracle as of version 5.3 dropped the Fixed performance regression caused by the fix for #3937 where\n+ Fixed performance regression caused by the fix for #3937 where\n cx_Oracle as of version 5.3 dropped the Fixed performance regression caused by the fix for #3937 where\n+ Fixed performance regression caused by the fix for #3937 where\n cx_Oracle as of version 5.3 dropped the Some modifications to how the cx_oracle dialect sets up per-column\n-outputtype handlers for LOB and numeric datatypes to adjust for potential\n-changes coming in cx_Oracle 8. References: #52461.0 Changelog\u00b6
\n 1.0.19\u00b6
\n Released: August 3, 2017oracle\u00b6
\n \n-
.UNICODE
symbol from its\n namespace, which was interpreted as cx_Oracle\u2019s \u201cWITH_UNICODE\u201d mode being\n turned on unconditionally, which invokes functions on the SQLAlchemy\n side which convert all strings to unicode unconditionally and causing\n a performance impact. In fact, per cx_Oracle\u2019s author the\n \u201cWITH_UNICODE\u201d mode has been removed entirely as of 5.1, so the expensive unicode\n conversion functions are no longer necessary and are disabled if\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -318,15 +318,15 @@\n # _\bo_\br_\ba_\bc_\bl_\be\n # _\bt_\be_\bs_\bt_\bs\n # _\bm_\bi_\bs_\bc\n *\b**\b**\b**\b**\b**\b* 1\b1.\b.0\b0 C\bCh\bha\ban\bng\bge\bel\blo\bog\bg_\b?\b\u00b6 *\b**\b**\b**\b**\b**\b*\n *\b**\b**\b**\b**\b* 1\b1.\b.0\b0.\b.1\b19\b9_\b?\b\u00b6 *\b**\b**\b**\b**\b*\n Released: August 3, 2017\n *\b**\b**\b**\b* o\bor\bra\bac\bcl\ble\be_\b?\b\u00b6 *\b**\b**\b**\b*\n- * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[p\bpy\by2\b2k\bk]\b] _\b\u00b6\n+ * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpy\by2\b2k\bk]\b] _\b\u00b6\n Fixed performance regression caused by the fix for _\b#_\b3_\b9_\b3_\b7 where cx_Oracle\n as of version 5.3 dropped the .UNICODE symbol from its namespace, which\n was interpreted as cx_Oracle\u2019s \u201cWITH_UNICODE\u201d mode being turned on\n unconditionally, which invokes functions on the SQLAlchemy side which\n convert all strings to unicode unconditionally and causing a performance\n impact. In fact, per cx_Oracle\u2019s author the \u201cWITH_UNICODE\u201d mode has been\n removed entirely as of 5.1, so the expensive unicode conversion functions\n"}]}, {"source1": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_11.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_11.html", "unified_diff": "@@ -875,15 +875,15 @@\n 1.1.13\u00b6
\n Released: August 3, 2017oracle\u00b6
\n \n-
\n .UNICODE
symbol from its\n namespace, which was interpreted as cx_Oracle\u2019s \u201cWITH_UNICODE\u201d mode being\n turned on unconditionally, which invokes functions on the SQLAlchemy\n side which convert all strings to unicode unconditionally and causing\n a performance impact. In fact, per cx_Oracle\u2019s author the\n \u201cWITH_UNICODE\u201d mode has been removed entirely as of 5.1, so the expensive unicode\n conversion functions are no longer necessary and are disabled if\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -496,15 +496,15 @@\n the same PRECEDING or FOLLOWING keywords in a range by allowing for the\n left side of the range to be positive and for the right to be negative,\n e.g. (1, 3) is \u201c1 FOLLOWING AND 3 FOLLOWING\u201d.\n References: _\b#_\b4_\b0_\b5_\b3\n *\b**\b**\b**\b**\b* 1\b1.\b.1\b1.\b.1\b13\b3_\b?\b\u00b6 *\b**\b**\b**\b**\b*\n Released: August 3, 2017\n *\b**\b**\b**\b* o\bor\bra\bac\bcl\ble\be_\b?\b\u00b6 *\b**\b**\b**\b*\n- * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[p\bpy\by2\b2k\bk]\b] _\b\u00b6\n+ * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpy\by2\b2k\bk]\b] _\b\u00b6\n Fixed performance regression caused by the fix for _\b#_\b3_\b9_\b3_\b7 where cx_Oracle\n as of version 5.3 dropped the .UNICODE symbol from its namespace, which\n was interpreted as cx_Oracle\u2019s \u201cWITH_UNICODE\u201d mode being turned on\n unconditionally, which invokes functions on the SQLAlchemy side which\n convert all strings to unicode unconditionally and causing a performance\n impact. In fact, per cx_Oracle\u2019s author the \u201cWITH_UNICODE\u201d mode has been\n removed entirely as of 5.1, so the expensive unicode conversion functions\n"}]}, {"source1": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_12.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_12.html", "unified_diff": "@@ -2977,15 +2977,15 @@\n oracle\u00b6
\n \n-
\n .UNICODE
symbol from its\n namespace, which was interpreted as cx_Oracle\u2019s \u201cWITH_UNICODE\u201d mode being\n turned on unconditionally, which invokes functions on the SQLAlchemy\n side which convert all strings to unicode unconditionally and causing\n a performance impact. In fact, per cx_Oracle\u2019s author the\n \u201cWITH_UNICODE\u201d mode has been removed entirely as of 5.1, so the expensive unicode\n conversion functions are no longer necessary and are disabled if\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -1879,15 +1879,15 @@\n verify the number of rows affected on a target version.\n [\b[m\bms\bss\bsq\bql\bl]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Added a rule to SQL Server index reflection to ignore the so-called \u201cheap\u201d\n index that is implicitly present on a table that does not specify a clustered\n index.\n References: _\b#_\b4_\b0_\b5_\b9\n *\b**\b**\b**\b* o\bor\bra\bac\bcl\ble\be_\b?\b\u00b6 *\b**\b**\b**\b*\n- * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[p\bpy\by2\b2k\bk]\b] _\b\u00b6\n+ * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpy\by2\b2k\bk]\b] _\b\u00b6\n Fixed performance regression caused by the fix for _\b#_\b3_\b9_\b3_\b7 where cx_Oracle\n as of version 5.3 dropped the .UNICODE symbol from its namespace, which\n was interpreted as cx_Oracle\u2019s \u201cWITH_UNICODE\u201d mode being turned on\n unconditionally, which invokes functions on the SQLAlchemy side which\n convert all strings to unicode unconditionally and causing a performance\n impact. In fact, per cx_Oracle\u2019s author the \u201cWITH_UNICODE\u201d mode has been\n removed entirely as of 5.1, so the expensive unicode conversion functions\n"}]}, {"source1": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_13.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_13.html", "unified_diff": "@@ -1803,30 +1803,30 @@\n oracle\u00b6
\n \n-
Changed the implementation of fetching CLOB and BLOB objects to use\n+
Changed the implementation of fetching CLOB and BLOB objects to use\n cx_Oracle\u2019s native implementation which fetches CLOB/BLOB objects inline\n with other result columns, rather than performing a separate fetch. As\n always, this can be disabled by setting auto_convert_lobs to False.
\nAs part of this change, the behavior of a CLOB that was given a blank\n string on INSERT now returns None on SELECT, which is now consistent with\n that of VARCHAR on Oracle.
\nReferences: #5314
\n \nSome modifications to how the cx_oracle dialect sets up per-column\n+outputtype handlers for LOB and numeric datatypes to adjust for potential\n+changes coming in cx_Oracle 8.
\n+References: #5246
\n+\n+Adjusted dialect loading for firebird://
URIs so the external\n sqlalchemy-firebird dialect will be used if it has been installed,\n@@ -2204,15 +2204,15 @@\n
Added keyword arguments to the MutableList.sort()
function so that a\n key function as well as the \u201creverse\u201d keyword argument can be provided.
References: #5114
\n \nRevised an internal change to the test system added as a result of\n+
Revised an internal change to the test system added as a result of\n #5085 where a testing-related module per dialect would be loaded\n unconditionally upon making use of that dialect, pulling in SQLAlchemy\u2019s\n testing framework as well as the ORM into the module import space. This\n would only impact initial startup time and memory to a modest extent,\n however it\u2019s best that these additional modules aren\u2019t reverse-dependent on\n straight Core usage.
\nReferences: #5180
\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -1144,28 +1144,28 @@\n References: _\b#_\b5_\b2_\b5_\b5\n [\b[m\bms\bss\bsq\bql\bl]\b] [\b[b\bbu\bug\bg]\b] [\b[r\bre\bef\bfl\ble\bec\bct\bti\bio\bon\bn]\b] _\b\u00b6\n Fix a regression introduced by the reflection of computed column in MSSQL when\n using SQL server versions before 2012, which does not support the concat\n function.\n References: _\b#_\b5_\b2_\b7_\b1\n *\b**\b**\b**\b* o\bor\bra\bac\bcl\ble\be_\b?\b\u00b6 *\b**\b**\b**\b*\n- * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n- Some modifications to how the cx_oracle dialect sets up per-column\n- outputtype handlers for LOB and numeric datatypes to adjust for potential\n- changes coming in cx_Oracle 8.\n- References: _\b#_\b5_\b2_\b4_\b6\n-[\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n-Changed the implementation of fetching CLOB and BLOB objects to use cx_Oracle\u2019s\n-native implementation which fetches CLOB/BLOB objects inline with other result\n-columns, rather than performing a separate fetch. As always, this can be\n-disabled by setting auto_convert_lobs to False.\n-As part of this change, the behavior of a CLOB that was given a blank string on\n-INSERT now returns None on SELECT, which is now consistent with that of VARCHAR\n-on Oracle.\n-References: _\b#_\b5_\b3_\b1_\b4\n+ * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n+ Changed the implementation of fetching CLOB and BLOB objects to use\n+ cx_Oracle\u2019s native implementation which fetches CLOB/BLOB objects inline\n+ with other result columns, rather than performing a separate fetch. As\n+ always, this can be disabled by setting auto_convert_lobs to False.\n+ As part of this change, the behavior of a CLOB that was given a blank\n+ string on INSERT now returns None on SELECT, which is now consistent with\n+ that of VARCHAR on Oracle.\n+ References: _\b#_\b5_\b3_\b1_\b4\n+[\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n+Some modifications to how the cx_oracle dialect sets up per-column outputtype\n+handlers for LOB and numeric datatypes to adjust for potential changes coming\n+in cx_Oracle 8.\n+References: _\b#_\b5_\b2_\b4_\b6\n *\b**\b**\b**\b* m\bmi\bis\bsc\bc_\b?\b\u00b6 *\b**\b**\b**\b*\n * [\b[c\bch\bha\ban\bng\bge\be]\b] [\b[f\bfi\bir\bre\beb\bbi\bir\brd\bd]\b] _\b\u00b6\n Adjusted dialect loading for firebird:// URIs so the external sqlalchemy-\n firebird dialect will be used if it has been installed, otherwise fall\n back to the (now deprecated) internal Firebird dialect.\n References: _\b#_\b5_\b2_\b7_\b8\n *\b**\b**\b**\b**\b* 1\b1.\b.3\b3.\b.1\b16\b6_\b?\b\u00b6 *\b**\b**\b**\b**\b*\n@@ -1409,15 +1409,15 @@\n but owned by someone else. Pull request courtesy Dave Hirschfeld.\n References: _\b#_\b5_\b1_\b4_\b6\n *\b**\b**\b**\b* m\bmi\bis\bsc\bc_\b?\b\u00b6 *\b**\b**\b**\b*\n * [\b[u\bus\bse\bec\bca\bas\bse\be]\b] [\b[e\bex\bxt\bt]\b] _\b\u00b6\n Added keyword arguments to the _\bM_\bu_\bt_\ba_\bb_\bl_\be_\bL_\bi_\bs_\bt_\b._\bs_\bo_\br_\bt_\b(_\b) function so that a key\n function as well as the \u201creverse\u201d keyword argument can be provided.\n References: _\b#_\b5_\b1_\b1_\b4\n-[\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n+[\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Revised an internal change to the test system added as a result of _\b#_\b5_\b0_\b8_\b5 where\n a testing-related module per dialect would be loaded unconditionally upon\n making use of that dialect, pulling in SQLAlchemy\u2019s testing framework as well\n as the ORM into the module import space. This would only impact initial startup\n time and memory to a modest extent, however it\u2019s best that these additional\n modules aren\u2019t reverse-dependent on straight Core usage.\n References: _\b#_\b5_\b1_\b8_\b0\n"}]}, {"source1": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_14.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_14.html", "unified_diff": "@@ -3065,36 +3065,36 @@\n attributes and entities that are installed as part of anInsert
,\n Update
, or Delete
construct. The\n Select.column_descriptions
accessor is also now implemented for\n Core-only selectables.\n References: #7861
\n \nFixed regression in \u201cdynamic\u201d loader strategy where the\n+
Improvements in memory usage by the ORM, removing a significant set of\n+intermediary expression objects that are typically stored when a copy of an\n+expression object is created. These clones have been greatly reduced,\n+reducing the number of total expression objects stored in memory by\n+ORM mappings by about 30%.
\n+References: #7823
\n+\n+Fixed regression in \u201cdynamic\u201d loader strategy where the\n Query.filter_by()
method would not be given an appropriate\n entity to filter from, in the case where a \u201csecondary\u201d table were present\n in the relationship being queried and the mapping were against something\n complex such as a \u201cwith polymorphic\u201d.
References: #7868
\n \nFixed bug where composite()
attributes would not work in\n+
Fixed bug where composite()
attributes would not work in\n conjunction with the selectin_polymorphic()
loader strategy for\n joined table inheritance.
References: #7801
\n \nImprovements in memory usage by the ORM, removing a significant set of\n-intermediary expression objects that are typically stored when a copy of an\n-expression object is created. These clones have been greatly reduced,\n-reducing the number of total expression objects stored in memory by\n-ORM mappings by about 30%.
\n-References: #7823
\n-\n-Fixed issue where the selectin_polymorphic()
loader option would\n not work with joined inheritance mappers that don\u2019t have a fixed\n \u201cpolymorphic_on\u201d column. Additionally added test support for a wider\n variety of usage patterns with this construct.
References: #7799
\n \nAdded a CAST(VARCHAR2(128)) to the \u201ctable name\u201d, \u201cowner\u201d, and other\n+
Added a CAST(VARCHAR2(128)) to the \u201ctable name\u201d, \u201cowner\u201d, and other\n DDL-name parameters as used in reflection queries against Oracle system\n views such as ALL_TABLES, ALL_TAB_CONSTRAINTS, etc to better enable\n indexing to take place against these columns, as they previously would be\n implicitly handled as NVARCHAR2 due to Python\u2019s use of Unicode for strings;\n these columns are documented in all Oracle versions as being VARCHAR2 with\n lengths varying from 30 to 128 characters depending on server version.\n Additionally, test support has been enabled for Unicode-named DDL\n@@ -5544,15 +5544,24 @@\n
Clarified the current purpose of the\n+
Fixed regression involving how the ORM would resolve a given mapped column\n+to a result row, where under cases such as joined eager loading, a slightly\n+more expensive \u201cfallback\u201d could take place to set up this resolution due to\n+some logic that was removed since 1.3. The issue could also cause\n+deprecation warnings involving column resolution to be emitted when using a\n+1.4 style query with joined eager loading.
\n+References: #6596
\n+\n+Clarified the current purpose of the\n relationship.bake_queries
flag, which in 1.4 is to enable\n or disable \u201clambda caching\u201d of statements within the \u201clazyload\u201d and\n \u201cselectinload\u201d loader strategies; this is separate from the more\n foundational SQL query cache that is used for most statements.\n Additionally, the lazy loader no longer uses its own cache for many-to-one\n SQL queries, which was an implementation quirk that doesn\u2019t exist for any\n other loader scenario. Finally, the \u201clru cache\u201d warning that the lazyloader\n@@ -5562,38 +5571,29 @@\n setting bake_queries=False
for such a relationship will remove this\n cache from being used, there\u2019s no particular performance gain in this case\n as using no caching vs. using a cache that needs to refresh often likely\n still wins out on the caching being used side.
Adjusted the means by which classes such as scoped_session
\n+
Adjusted the means by which classes such as scoped_session
\n and AsyncSession
are generated from the base\n Session
class, such that custom Session
\n subclasses such as that used by Flask-SQLAlchemy don\u2019t need to implement\n positional arguments when they call into the superclass method, and can\n continue using the same argument styles as in previous releases.
References: #6285
\n \nFixed issue where query production for joinedload against a complex left\n+
Fixed issue where query production for joinedload against a complex left\n hand side involving joined-table inheritance could fail to produce a\n correct query, due to a clause adaption issue.
\nReferences: #6595
\n \nFixed regression involving how the ORM would resolve a given mapped column\n-to a result row, where under cases such as joined eager loading, a slightly\n-more expensive \u201cfallback\u201d could take place to set up this resolution due to\n-some logic that was removed since 1.3. The issue could also cause\n-deprecation warnings involving column resolution to be emitted when using a\n-1.4 style query with joined eager loading.
\n-References: #6596
\n-\n-Fixed issue in experimental \u201cselect ORM objects from INSERT/UPDATE\u201d use\n case where an error was raised if the statement were against a\n single-table-inheritance subclass.
\nReferences: #6591
\n \nThe warning that\u2019s emitted for relationship()
when multiple\n@@ -6437,15 +6437,15 @@\n synonyms can be established linking to these constructs which work\n fully. This is a behavior that was semi-explicitly disallowed previously,\n however since it did not fail in every scenario, explicit support\n for assoc proxy and hybrids has been added.
References: #6267
\n \nFixed a critical performance issue where the traversal of a\n+
Fixed a critical performance issue where the traversal of a\n select()
construct would traverse a repetitive product of the\n represented FROM clauses as they were each referenced by columns in\n the columns clause; for a series of nested subqueries with lots of columns\n this could cause a large delay and significant memory growth. This\n traversal is used by a wide variety of SQL and ORM functions, including by\n the ORM Session
when it\u2019s configured to have\n \u201ctable-per-bind\u201d, which while this is not a common use case, it seems to be\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -2032,31 +2032,31 @@\n [\b[o\bor\brm\bm]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n Added new attributes _\bU_\bp_\bd_\ba_\bt_\be_\bB_\ba_\bs_\be_\b._\br_\be_\bt_\bu_\br_\bn_\bi_\bn_\bg_\b__\bc_\bo_\bl_\bu_\bm_\bn_\b__\bd_\be_\bs_\bc_\br_\bi_\bp_\bt_\bi_\bo_\bn_\bs and\n _\bU_\bp_\bd_\ba_\bt_\be_\bB_\ba_\bs_\be_\b._\be_\bn_\bt_\bi_\bt_\by_\b__\bd_\be_\bs_\bc_\br_\bi_\bp_\bt_\bi_\bo_\bn to allow for inspection of ORM attributes and\n entities that are installed as part of an _\bI_\bn_\bs_\be_\br_\bt, _\bU_\bp_\bd_\ba_\bt_\be, or _\bD_\be_\bl_\be_\bt_\be construct.\n The _\bS_\be_\bl_\be_\bc_\bt_\b._\bc_\bo_\bl_\bu_\bm_\bn_\b__\bd_\be_\bs_\bc_\br_\bi_\bp_\bt_\bi_\bo_\bn_\bs accessor is also now implemented for Core-only\n selectables.\n References: _\b#_\b7_\b8_\b6_\b1\n+[\b[o\bor\brm\bm]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n+Improvements in memory usage by the ORM, removing a significant set of\n+intermediary expression objects that are typically stored when a copy of an\n+expression object is created. These clones have been greatly reduced, reducing\n+the number of total expression objects stored in memory by ORM mappings by\n+about 30%.\n+References: _\b#_\b7_\b8_\b2_\b3\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] [\b[r\bre\beg\bgr\bre\bes\bss\bsi\bio\bon\bn]\b] _\b\u00b6\n Fixed regression in \u201cdynamic\u201d loader strategy where the _\bQ_\bu_\be_\br_\by_\b._\bf_\bi_\bl_\bt_\be_\br_\b__\bb_\by_\b(_\b)\n method would not be given an appropriate entity to filter from, in the case\n where a \u201csecondary\u201d table were present in the relationship being queried and\n the mapping were against something complex such as a \u201cwith polymorphic\u201d.\n References: _\b#_\b7_\b8_\b6_\b8\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Fixed bug where _\bc_\bo_\bm_\bp_\bo_\bs_\bi_\bt_\be_\b(_\b) attributes would not work in conjunction with the\n _\bs_\be_\bl_\be_\bc_\bt_\bi_\bn_\b__\bp_\bo_\bl_\by_\bm_\bo_\br_\bp_\bh_\bi_\bc_\b(_\b) loader strategy for joined table inheritance.\n References: _\b#_\b7_\b8_\b0_\b1\n-[\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n-Improvements in memory usage by the ORM, removing a significant set of\n-intermediary expression objects that are typically stored when a copy of an\n-expression object is created. These clones have been greatly reduced, reducing\n-the number of total expression objects stored in memory by ORM mappings by\n-about 30%.\n-References: _\b#_\b7_\b8_\b2_\b3\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Fixed issue where the _\bs_\be_\bl_\be_\bc_\bt_\bi_\bn_\b__\bp_\bo_\bl_\by_\bm_\bo_\br_\bp_\bh_\bi_\bc_\b(_\b) loader option would not work with\n joined inheritance mappers that don\u2019t have a fixed \u201cpolymorphic_on\u201d column.\n Additionally added test support for a wider variety of usage patterns with this\n construct.\n References: _\b#_\b7_\b7_\b9_\b9\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n@@ -3255,15 +3255,15 @@\n * [\b[m\bms\bss\bsq\bql\bl]\b] [\b[b\bbu\bug\bg]\b] [\b[r\bre\bef\bfl\ble\bec\bct\bti\bio\bon\bn]\b] _\b\u00b6\n Fixed an issue where sqlalchemy.engine.reflection.has_table() returned\n True for local temporary tables that actually belonged to a different SQL\n Server session (connection). An extra check is now performed to ensure\n that the temp table detected is in fact owned by the current session.\n References: _\b#_\b6_\b9_\b1_\b0\n *\b**\b**\b**\b* o\bor\bra\bac\bcl\ble\be_\b?\b\u00b6 *\b**\b**\b**\b*\n- * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n+ * [\b[o\bor\bra\bac\bcl\ble\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Added a CAST(VARCHAR2(128)) to the \u201ctable name\u201d, \u201cowner\u201d, and other DDL-\n name parameters as used in reflection queries against Oracle system views\n such as ALL_TABLES, ALL_TAB_CONSTRAINTS, etc to better enable indexing to\n take place against these columns, as they previously would be implicitly\n handled as NVARCHAR2 due to Python\u2019s use of Unicode for strings; these\n columns are documented in all Oracle versions as being VARCHAR2 with\n lengths varying from 30 to 128 characters depending on server version.\n@@ -3763,51 +3763,50 @@\n the INSERT thus triggering SQLAlchemy\u2019s feature of setting IDENTITY INSERT to\n \u201con\u201d; it\u2019s in this directive where the schema translate map would fail to be\n honored.\n References: _\b#_\b6_\b6_\b5_\b8\n *\b**\b**\b**\b**\b* 1\b1.\b.4\b4.\b.1\b18\b8_\b?\b\u00b6 *\b**\b**\b**\b**\b*\n Released: June 10, 2021\n *\b**\b**\b**\b* o\bor\brm\bm_\b?\b\u00b6 *\b**\b**\b**\b*\n- * [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n- Clarified the current purpose of the _\br_\be_\bl_\ba_\bt_\bi_\bo_\bn_\bs_\bh_\bi_\bp_\b._\bb_\ba_\bk_\be_\b__\bq_\bu_\be_\br_\bi_\be_\bs flag,\n- which in 1.4 is to enable or disable \u201clambda caching\u201d of statements\n- within the \u201clazyload\u201d and \u201cselectinload\u201d loader strategies; this is\n- separate from the more foundational SQL query cache that is used for most\n- statements. Additionally, the lazy loader no longer uses its own cache\n- for many-to-one SQL queries, which was an implementation quirk that\n- doesn\u2019t exist for any other loader scenario. Finally, the \u201clru cache\u201d\n- warning that the lazyloader and selectinloader strategies could emit when\n- handling a wide array of class/relationship combinations has been\n- removed; based on analysis of some end-user cases, this warning doesn\u2019t\n- suggest any significant issue. While setting bake_queries=False for such\n- a relationship will remove this cache from being used, there\u2019s no\n- particular performance gain in this case as using no caching vs. using a\n- cache that needs to refresh often likely still wins out on the caching\n- being used side.\n- References: _\b#_\b6_\b0_\b7_\b2, _\b#_\b6_\b4_\b8_\b7\n+ * [\b[o\bor\brm\bm]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] [\b[r\bre\beg\bgr\bre\bes\bss\bsi\bio\bon\bn]\b] _\b\u00b6\n+ Fixed regression involving how the ORM would resolve a given mapped\n+ column to a result row, where under cases such as joined eager loading, a\n+ slightly more expensive \u201cfallback\u201d could take place to set up this\n+ resolution due to some logic that was removed since 1.3. The issue could\n+ also cause deprecation warnings involving column resolution to be emitted\n+ when using a 1.4 style query with joined eager loading.\n+ References: _\b#_\b6_\b5_\b9_\b6\n+[\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n+Clarified the current purpose of the _\br_\be_\bl_\ba_\bt_\bi_\bo_\bn_\bs_\bh_\bi_\bp_\b._\bb_\ba_\bk_\be_\b__\bq_\bu_\be_\br_\bi_\be_\bs flag, which in\n+1.4 is to enable or disable \u201clambda caching\u201d of statements within the\n+\u201clazyload\u201d and \u201cselectinload\u201d loader strategies; this is separate from the more\n+foundational SQL query cache that is used for most statements. Additionally,\n+the lazy loader no longer uses its own cache for many-to-one SQL queries, which\n+was an implementation quirk that doesn\u2019t exist for any other loader scenario.\n+Finally, the \u201clru cache\u201d warning that the lazyloader and selectinloader\n+strategies could emit when handling a wide array of class/relationship\n+combinations has been removed; based on analysis of some end-user cases, this\n+warning doesn\u2019t suggest any significant issue. While setting bake_queries=False\n+for such a relationship will remove this cache from being used, there\u2019s no\n+particular performance gain in this case as using no caching vs. using a cache\n+that needs to refresh often likely still wins out on the caching being used\n+side.\n+References: _\b#_\b6_\b0_\b7_\b2, _\b#_\b6_\b4_\b8_\b7\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] [\b[r\bre\beg\bgr\bre\bes\bss\bsi\bio\bon\bn]\b] _\b\u00b6\n Adjusted the means by which classes such as _\bs_\bc_\bo_\bp_\be_\bd_\b__\bs_\be_\bs_\bs_\bi_\bo_\bn and _\bA_\bs_\by_\bn_\bc_\bS_\be_\bs_\bs_\bi_\bo_\bn are\n generated from the base _\bS_\be_\bs_\bs_\bi_\bo_\bn class, such that custom _\bS_\be_\bs_\bs_\bi_\bo_\bn subclasses such\n as that used by Flask-SQLAlchemy don\u2019t need to implement positional arguments\n when they call into the superclass method, and can continue using the same\n argument styles as in previous releases.\n References: _\b#_\b6_\b2_\b8_\b5\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] [\b[r\bre\beg\bgr\bre\bes\bss\bsi\bio\bon\bn]\b] _\b\u00b6\n Fixed issue where query production for joinedload against a complex left hand\n side involving joined-table inheritance could fail to produce a correct query,\n due to a clause adaption issue.\n References: _\b#_\b6_\b5_\b9_\b5\n-[\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[r\bre\beg\bgr\bre\bes\bss\bsi\bio\bon\bn]\b] _\b\u00b6\n-Fixed regression involving how the ORM would resolve a given mapped column to a\n-result row, where under cases such as joined eager loading, a slightly more\n-expensive \u201cfallback\u201d could take place to set up this resolution due to some\n-logic that was removed since 1.3. The issue could also cause deprecation\n-warnings involving column resolution to be emitted when using a 1.4 style query\n-with joined eager loading.\n-References: _\b#_\b6_\b5_\b9_\b6\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Fixed issue in experimental \u201cselect ORM objects from INSERT/UPDATE\u201d use case\n where an error was raised if the statement were against a single-table-\n inheritance subclass.\n References: _\b#_\b6_\b5_\b9_\b1\n [\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n The warning that\u2019s emitted for _\br_\be_\bl_\ba_\bt_\bi_\bo_\bn_\bs_\bh_\bi_\bp_\b(_\b) when multiple relationships would\n@@ -4377,15 +4376,15 @@\n Established support for synoynm() in conjunction with hybrid property,\n assocaitionproxy is set up completely, including that synonyms can be\n established linking to these constructs which work fully. This is a\n behavior that was semi-explicitly disallowed previously, however since it\n did not fail in every scenario, explicit support for assoc proxy and\n hybrids has been added.\n References: _\b#_\b6_\b2_\b6_\b7\n-[\b[o\bor\brm\bm]\b] [\b[b\bbu\bug\bg]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[r\bre\beg\bgr\bre\bes\bss\bsi\bio\bon\bn]\b] [\b[s\bsq\bql\bl]\b] _\b\u00b6\n+[\b[o\bor\brm\bm]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[b\bbu\bug\bg]\b] [\b[r\bre\beg\bgr\bre\bes\bss\bsi\bio\bon\bn]\b] [\b[s\bsq\bql\bl]\b] _\b\u00b6\n Fixed a critical performance issue where the traversal of a _\bs_\be_\bl_\be_\bc_\bt_\b(_\b) construct\n would traverse a repetitive product of the represented FROM clauses as they\n were each referenced by columns in the columns clause; for a series of nested\n subqueries with lots of columns this could cause a large delay and significant\n memory growth. This traversal is used by a wide variety of SQL and ORM\n functions, including by the ORM _\bS_\be_\bs_\bs_\bi_\bo_\bn when it\u2019s configured to have \u201ctable-\n per-bind\u201d, which while this is not a common use case, it seems to be what\n"}]}, {"source1": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_20.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_20.html", "unified_diff": "@@ -1573,32 +1573,32 @@\n
Fixed regression caused by #9779 where using the \u201csecondary\u201d table\n-in a relationship and_()
expression would fail to be aliased to match\n-how the \u201csecondary\u201d table normally renders within a\n-Select.join()
expression, leading to an invalid query.
References: #11010
\n-\n-Adjusted the fix made in #10570, released in 2.0.23, where new\n+
Adjusted the fix made in #10570, released in 2.0.23, where new\n logic was added to reconcile possibly changing bound parameter values\n across cache key generations used within the with_expression()
\n construct. The new logic changes the approach by which the new bound\n parameter values are associated with the statement, avoiding the need to\n deep-copy the statement which can result in a significant performance\n penalty for very deep / complex SQL constructs. The new approach no longer\n requires this deep-copy step.
References: #11085
\n \nFixed regression caused by #9779 where using the \u201csecondary\u201d table\n+in a relationship and_()
expression would fail to be aliased to match\n+how the \u201csecondary\u201d table normally renders within a\n+Select.join()
expression, leading to an invalid query.
References: #11010
\n+\n+Added new core execution option\n Connection.execution_options.preserve_rowcount
. When\n@@ -1831,15 +1831,15 @@\n
Changed the default arraysize of the Oracle dialects so that the value set\n+
Changed the default arraysize of the Oracle dialects so that the value set\n by the driver is used, that is 100 at the time of writing for both\n cx_oracle and oracledb. Previously the value was set to 50 by default. The\n setting of 50 could cause significant performance regressions compared to\n when using cx_oracle/oracledb alone to fetch many hundreds of rows over\n slower networks.
\nReferences: #10877
\n \n@@ -6073,39 +6073,39 @@\nrelationship()
etc. to provide for the Python dataclasses\n compare
parameter on field()
, when using the\n Declarative Dataclass Mapping feature. Pull request courtesy\n Simon Schiele.\n References: #8905
\n \nFixed issue where use of an unknown datatype within a Mapped
\n+
Additional performance enhancements within ORM-enabled SQL statements,\n+specifically targeting callcounts within the construction of ORM\n+statements, using combinations of aliased()
with\n+union()
and similar \u201ccompound\u201d constructs, in addition to direct\n+performance improvements to the corresponding_column()
internal method\n+that is used heavily by the ORM by constructs like aliased()
and\n+similar.
References: #8796
\n+\n+Fixed issue where use of an unknown datatype within a Mapped
\n annotation for a column-based attribute would silently fail to map the\n attribute, rather than reporting an exception; an informative exception\n message is now raised.
References: #8888
\n \nFixed a suite of issues involving Mapped
use with dictionary\n+
Fixed a suite of issues involving Mapped
use with dictionary\n types, such as Mapped[Dict[str, str] | None]
, would not be correctly\n interpreted in Declarative ORM mappings. Support to correctly\n \u201cde-optionalize\u201d this type including for lookup in type_annotation_map
\n has been fixed.
References: #8777
\n \nAdditional performance enhancements within ORM-enabled SQL statements,\n-specifically targeting callcounts within the construction of ORM\n-statements, using combinations of aliased()
with\n-union()
and similar \u201ccompound\u201d constructs, in addition to direct\n-performance improvements to the corresponding_column()
internal method\n-that is used heavily by the ORM by constructs like aliased()
and\n-similar.
References: #8796
\n-\n-Fixed bug in Declarative Dataclass Mapping feature where using\n plain dataclass fields with the __allow_unmapped__
directive in a\n mapping would not create a dataclass with the correct class-level state for\n those fields, copying the raw Field
object to the class inappropriately\n after dataclasses itself had replaced the Field
object with the\n class-level default value.
References: #8880
\n@@ -7935,32 +7935,46 @@\n \nAdded RETURNING support for the SQLite dialect. SQLite supports RETURNING\n since version 3.35.
\nReferences: #6195
\n \nSQLite datetime, date, and time datatypes now use Python standard lib\n+
The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements\n+that may refer to additional tables within the WHERE criteria of the\n+statement without the need to use subqueries. This syntax is invoked\n+automatically when using the Update
construct when more than\n+one table or other entity or selectable is used.
References: #7185
\n+\n+The SQLite dialect now defaults to QueuePool
when a file\n+based database is used. This is set along with setting the\n+check_same_thread
parameter to False
. It has been observed that the\n+previous approach of defaulting to NullPool
, which does not\n+hold onto database connections after they are released, did in fact have a\n+measurable negative performance impact. As always, the pool class is\n+customizable via the create_engine.poolclass
parameter.
See also
\n+\n+References: #7490
\n+\n+SQLite datetime, date, and time datatypes now use Python standard lib\n fromisoformat()
methods in order to parse incoming datetime, date, and\n time string values. This improves performance vs. the previous regular\n expression-based approach, and also automatically accommodates for datetime\n and time formats that contain either a six-digit \u201cmicroseconds\u201d format or a\n three-digit \u201cmilliseconds\u201d format.
References: #7029
\n \nThe SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements\n-that may refer to additional tables within the WHERE criteria of the\n-statement without the need to use subqueries. This syntax is invoked\n-automatically when using the Update
construct when more than\n-one table or other entity or selectable is used.
References: #7185
\n-\n-Removed the warning that emits from the Numeric
type about\n+
Removed the warning that emits from the Numeric
type about\n DBAPIs not supporting Decimal values natively. This warning was oriented\n towards SQLite, which does not have any real way without additional\n extensions or workarounds of handling precision numeric values more than 15\n significant digits as it only uses floating point math to represent\n numbers. As this is a known and documented limitation in SQLite itself, and\n not a quirk of the pysqlite driver, there\u2019s no need for SQLAlchemy to warn\n for this. The change does not otherwise modify how precision numerics are\n@@ -7968,28 +7982,14 @@\n as configured with the Numeric
, Float
, and\n related datatypes, just without the ability to maintain precision beyond 15\n significant digits when using SQLite, unless alternate representations such\n as strings are used.
References: #7299
\n \nThe SQLite dialect now defaults to QueuePool
when a file\n-based database is used. This is set along with setting the\n-check_same_thread
parameter to False
. It has been observed that the\n-previous approach of defaulting to NullPool
, which does not\n-hold onto database connections after they are released, did in fact have a\n-measurable negative performance impact. As always, the pool class is\n-customizable via the create_engine.poolclass
parameter.
See also
\n-\n-References: #7490
\n-\n-Implemented reflection of the \u201cclustered index\u201d flag mssql_clustered
\n for the SQL Server dialect. Pull request courtesy John Lennox.