--- /srv/reproducible-results/rbuild-debian/r-b-build.3varpeu8/b1/sqlalchemy_2.0.32+ds1-1_arm64.changes
+++ /srv/reproducible-results/rbuild-debian/r-b-build.3varpeu8/b2/sqlalchemy_2.0.32+ds1-1_arm64.changes
├── Files
│ @@ -1,5 +1,5 @@
│
│ - b9e70906592f992dbf2d1aa463801683 3956236 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb
│ + f62e6412c540309ad082e1c51d7ae62b 3956340 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb
│ e952a5b72ab352fb36a73a20f1094749 887488 debug optional python3-sqlalchemy-ext-dbgsym_2.0.32+ds1-1_arm64.deb
│ 80278345cb1edf5a3a6f8fbc7713af07 123036 python optional python3-sqlalchemy-ext_2.0.32+ds1-1_arm64.deb
│ a41827cb43c13a1500ad805e14b01e17 1196228 python optional python3-sqlalchemy_2.0.32+ds1-1_all.deb
├── python-sqlalchemy-doc_2.0.32+ds1-1_all.deb
│ ├── file list
│ │ @@ -1,3 +1,3 @@
│ │ -rw-r--r-- 0 0 0 4 2024-08-23 07:52:58.000000 debian-binary
│ │ --rw-r--r-- 0 0 0 13928 2024-08-23 07:52:58.000000 control.tar.xz
│ │ --rw-r--r-- 0 0 0 3942116 2024-08-23 07:52:58.000000 data.tar.xz
│ │ +-rw-r--r-- 0 0 0 13932 2024-08-23 07:52:58.000000 control.tar.xz
│ │ +-rw-r--r-- 0 0 0 3942216 2024-08-23 07:52:58.000000 data.tar.xz
│ ├── control.tar.xz
│ │ ├── control.tar
│ │ │ ├── ./md5sums
│ │ │ │ ├── ./md5sums
│ │ │ │ │┄ Files differ
│ ├── data.tar.xz
│ │ ├── data.tar
│ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_10.html
│ │ │ │ @@ -592,15 +592,15 @@
│ │ │ │ Fixed performance regression caused by the fix for #3937 where
│ │ │ │ + Fixed performance regression caused by the fix for #3937 where
│ │ │ │ cx_Oracle as of version 5.3 dropped the Fixed performance regression caused by the fix for #3937 where
│ │ │ │ + Fixed performance regression caused by the fix for #3937 where
│ │ │ │ cx_Oracle as of version 5.3 dropped the Fixed performance regression caused by the fix for #3937 where
│ │ │ │ + Fixed performance regression caused by the fix for #3937 where
│ │ │ │ cx_Oracle as of version 5.3 dropped the Some modifications to how the cx_oracle dialect sets up per-column
│ │ │ │ -outputtype handlers for LOB and numeric datatypes to adjust for potential
│ │ │ │ -changes coming in cx_Oracle 8. References: #52461.0 Changelog¶
│ │ │ │ 1.0.19¶
│ │ │ │ Released: August 3, 2017oracle¶
│ │ │ │
│ │ │ │ -
.UNICODE
symbol from its
│ │ │ │ namespace, which was interpreted as cx_Oracle’s “WITH_UNICODE” mode being
│ │ │ │ turned on unconditionally, which invokes functions on the SQLAlchemy
│ │ │ │ side which convert all strings to unicode unconditionally and causing
│ │ │ │ a performance impact. In fact, per cx_Oracle’s author the
│ │ │ │ “WITH_UNICODE” mode has been removed entirely as of 5.1, so the expensive unicode
│ │ │ │ conversion functions are no longer necessary and are disabled if
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -318,15 +318,15 @@
│ │ │ │ │ # _o_r_a_c_l_e
│ │ │ │ │ # _t_e_s_t_s
│ │ │ │ │ # _m_i_s_c
│ │ │ │ │ ************ 11..00 CChhaannggeelloogg_?¶ ************
│ │ │ │ │ ********** 11..00..1199_?¶ **********
│ │ │ │ │ Released: August 3, 2017
│ │ │ │ │ ******** oorraaccllee_?¶ ********
│ │ │ │ │ - * [[oorraaccllee]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] [[ppyy22kk]] _¶
│ │ │ │ │ + * [[oorraaccllee]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] [[ppyy22kk]] _¶
│ │ │ │ │ Fixed performance regression caused by the fix for _#_3_9_3_7 where cx_Oracle
│ │ │ │ │ as of version 5.3 dropped the .UNICODE symbol from its namespace, which
│ │ │ │ │ was interpreted as cx_Oracle’s “WITH_UNICODE” mode being turned on
│ │ │ │ │ unconditionally, which invokes functions on the SQLAlchemy side which
│ │ │ │ │ convert all strings to unicode unconditionally and causing a performance
│ │ │ │ │ impact. In fact, per cx_Oracle’s author the “WITH_UNICODE” mode has been
│ │ │ │ │ removed entirely as of 5.1, so the expensive unicode conversion functions
│ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_11.html
│ │ │ │ @@ -875,15 +875,15 @@
│ │ │ │ 1.1.13¶
│ │ │ │ Released: August 3, 2017oracle¶
│ │ │ │
│ │ │ │ -
│ │ │ │ .UNICODE
symbol from its
│ │ │ │ namespace, which was interpreted as cx_Oracle’s “WITH_UNICODE” mode being
│ │ │ │ turned on unconditionally, which invokes functions on the SQLAlchemy
│ │ │ │ side which convert all strings to unicode unconditionally and causing
│ │ │ │ a performance impact. In fact, per cx_Oracle’s author the
│ │ │ │ “WITH_UNICODE” mode has been removed entirely as of 5.1, so the expensive unicode
│ │ │ │ conversion functions are no longer necessary and are disabled if
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -496,15 +496,15 @@
│ │ │ │ │ the same PRECEDING or FOLLOWING keywords in a range by allowing for the
│ │ │ │ │ left side of the range to be positive and for the right to be negative,
│ │ │ │ │ e.g. (1, 3) is “1 FOLLOWING AND 3 FOLLOWING”.
│ │ │ │ │ References: _#_4_0_5_3
│ │ │ │ │ ********** 11..11..1133_?¶ **********
│ │ │ │ │ Released: August 3, 2017
│ │ │ │ │ ******** oorraaccllee_?¶ ********
│ │ │ │ │ - * [[oorraaccllee]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] [[ppyy22kk]] _¶
│ │ │ │ │ + * [[oorraaccllee]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] [[ppyy22kk]] _¶
│ │ │ │ │ Fixed performance regression caused by the fix for _#_3_9_3_7 where cx_Oracle
│ │ │ │ │ as of version 5.3 dropped the .UNICODE symbol from its namespace, which
│ │ │ │ │ was interpreted as cx_Oracle’s “WITH_UNICODE” mode being turned on
│ │ │ │ │ unconditionally, which invokes functions on the SQLAlchemy side which
│ │ │ │ │ convert all strings to unicode unconditionally and causing a performance
│ │ │ │ │ impact. In fact, per cx_Oracle’s author the “WITH_UNICODE” mode has been
│ │ │ │ │ removed entirely as of 5.1, so the expensive unicode conversion functions
│ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_12.html
│ │ │ │ @@ -2977,15 +2977,15 @@
│ │ │ │ oracle¶
│ │ │ │
│ │ │ │ -
│ │ │ │ .UNICODE
symbol from its
│ │ │ │ namespace, which was interpreted as cx_Oracle’s “WITH_UNICODE” mode being
│ │ │ │ turned on unconditionally, which invokes functions on the SQLAlchemy
│ │ │ │ side which convert all strings to unicode unconditionally and causing
│ │ │ │ a performance impact. In fact, per cx_Oracle’s author the
│ │ │ │ “WITH_UNICODE” mode has been removed entirely as of 5.1, so the expensive unicode
│ │ │ │ conversion functions are no longer necessary and are disabled if
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -1879,15 +1879,15 @@
│ │ │ │ │ verify the number of rows affected on a target version.
│ │ │ │ │ [[mmssssqqll]] [[bbuugg]] _¶
│ │ │ │ │ Added a rule to SQL Server index reflection to ignore the so-called “heap”
│ │ │ │ │ index that is implicitly present on a table that does not specify a clustered
│ │ │ │ │ index.
│ │ │ │ │ References: _#_4_0_5_9
│ │ │ │ │ ******** oorraaccllee_?¶ ********
│ │ │ │ │ - * [[oorraaccllee]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] [[ppyy22kk]] _¶
│ │ │ │ │ + * [[oorraaccllee]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] [[ppyy22kk]] _¶
│ │ │ │ │ Fixed performance regression caused by the fix for _#_3_9_3_7 where cx_Oracle
│ │ │ │ │ as of version 5.3 dropped the .UNICODE symbol from its namespace, which
│ │ │ │ │ was interpreted as cx_Oracle’s “WITH_UNICODE” mode being turned on
│ │ │ │ │ unconditionally, which invokes functions on the SQLAlchemy side which
│ │ │ │ │ convert all strings to unicode unconditionally and causing a performance
│ │ │ │ │ impact. In fact, per cx_Oracle’s author the “WITH_UNICODE” mode has been
│ │ │ │ │ removed entirely as of 5.1, so the expensive unicode conversion functions
│ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_13.html
│ │ │ │ @@ -1803,30 +1803,30 @@
│ │ │ │ oracle¶
│ │ │ │
│ │ │ │ -
Changed the implementation of fetching CLOB and BLOB objects to use │ │ │ │ +
Changed the implementation of fetching CLOB and BLOB objects to use │ │ │ │ cx_Oracle’s native implementation which fetches CLOB/BLOB objects inline │ │ │ │ with other result columns, rather than performing a separate fetch. As │ │ │ │ always, this can be disabled by setting auto_convert_lobs to False.
│ │ │ │As part of this change, the behavior of a CLOB that was given a blank │ │ │ │ string on INSERT now returns None on SELECT, which is now consistent with │ │ │ │ that of VARCHAR on Oracle.
│ │ │ │References: #5314
│ │ │ │ │ │ │ │Some modifications to how the cx_oracle dialect sets up per-column │ │ │ │ +outputtype handlers for LOB and numeric datatypes to adjust for potential │ │ │ │ +changes coming in cx_Oracle 8.
│ │ │ │ +References: #5246
│ │ │ │ + │ │ │ │ +Adjusted dialect loading for firebird://
URIs so the external
│ │ │ │ sqlalchemy-firebird dialect will be used if it has been installed,
│ │ │ │ @@ -2204,15 +2204,15 @@
│ │ │ │
Added keyword arguments to the MutableList.sort()
function so that a
│ │ │ │ key function as well as the “reverse” keyword argument can be provided.
References: #5114
│ │ │ │ │ │ │ │Revised an internal change to the test system added as a result of │ │ │ │ +
Revised an internal change to the test system added as a result of │ │ │ │ #5085 where a testing-related module per dialect would be loaded │ │ │ │ unconditionally upon making use of that dialect, pulling in SQLAlchemy’s │ │ │ │ testing framework as well as the ORM into the module import space. This │ │ │ │ would only impact initial startup time and memory to a modest extent, │ │ │ │ however it’s best that these additional modules aren’t reverse-dependent on │ │ │ │ straight Core usage.
│ │ │ │References: #5180
│ │ │ │ ├── html2text {} │ │ │ │ │ @@ -1144,28 +1144,28 @@ │ │ │ │ │ References: _#_5_2_5_5 │ │ │ │ │ [[mmssssqqll]] [[bbuugg]] [[rreefflleeccttiioonn]] _¶ │ │ │ │ │ Fix a regression introduced by the reflection of computed column in MSSQL when │ │ │ │ │ using SQL server versions before 2012, which does not support the concat │ │ │ │ │ function. │ │ │ │ │ References: _#_5_2_7_1 │ │ │ │ │ ******** oorraaccllee_?¶ ******** │ │ │ │ │ - * [[oorraaccllee]] [[bbuugg]] _¶ │ │ │ │ │ - Some modifications to how the cx_oracle dialect sets up per-column │ │ │ │ │ - outputtype handlers for LOB and numeric datatypes to adjust for potential │ │ │ │ │ - changes coming in cx_Oracle 8. │ │ │ │ │ - References: _#_5_2_4_6 │ │ │ │ │ -[[oorraaccllee]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] _¶ │ │ │ │ │ -Changed the implementation of fetching CLOB and BLOB objects to use cx_Oracle’s │ │ │ │ │ -native implementation which fetches CLOB/BLOB objects inline with other result │ │ │ │ │ -columns, rather than performing a separate fetch. As always, this can be │ │ │ │ │ -disabled by setting auto_convert_lobs to False. │ │ │ │ │ -As part of this change, the behavior of a CLOB that was given a blank string on │ │ │ │ │ -INSERT now returns None on SELECT, which is now consistent with that of VARCHAR │ │ │ │ │ -on Oracle. │ │ │ │ │ -References: _#_5_3_1_4 │ │ │ │ │ + * [[oorraaccllee]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] _¶ │ │ │ │ │ + Changed the implementation of fetching CLOB and BLOB objects to use │ │ │ │ │ + cx_Oracle’s native implementation which fetches CLOB/BLOB objects inline │ │ │ │ │ + with other result columns, rather than performing a separate fetch. As │ │ │ │ │ + always, this can be disabled by setting auto_convert_lobs to False. │ │ │ │ │ + As part of this change, the behavior of a CLOB that was given a blank │ │ │ │ │ + string on INSERT now returns None on SELECT, which is now consistent with │ │ │ │ │ + that of VARCHAR on Oracle. │ │ │ │ │ + References: _#_5_3_1_4 │ │ │ │ │ +[[oorraaccllee]] [[bbuugg]] _¶ │ │ │ │ │ +Some modifications to how the cx_oracle dialect sets up per-column outputtype │ │ │ │ │ +handlers for LOB and numeric datatypes to adjust for potential changes coming │ │ │ │ │ +in cx_Oracle 8. │ │ │ │ │ +References: _#_5_2_4_6 │ │ │ │ │ ******** mmiisscc_?¶ ******** │ │ │ │ │ * [[cchhaannggee]] [[ffiirreebbiirrdd]] _¶ │ │ │ │ │ Adjusted dialect loading for firebird:// URIs so the external sqlalchemy- │ │ │ │ │ firebird dialect will be used if it has been installed, otherwise fall │ │ │ │ │ back to the (now deprecated) internal Firebird dialect. │ │ │ │ │ References: _#_5_2_7_8 │ │ │ │ │ ********** 11..33..1166_?¶ ********** │ │ │ │ │ @@ -1409,15 +1409,15 @@ │ │ │ │ │ but owned by someone else. Pull request courtesy Dave Hirschfeld. │ │ │ │ │ References: _#_5_1_4_6 │ │ │ │ │ ******** mmiisscc_?¶ ******** │ │ │ │ │ * [[uusseeccaassee]] [[eexxtt]] _¶ │ │ │ │ │ Added keyword arguments to the _M_u_t_a_b_l_e_L_i_s_t_._s_o_r_t_(_) function so that a key │ │ │ │ │ function as well as the “reverse” keyword argument can be provided. │ │ │ │ │ References: _#_5_1_1_4 │ │ │ │ │ -[[bbuugg]] [[ppeerrffoorrmmaannccee]] _¶ │ │ │ │ │ +[[ppeerrffoorrmmaannccee]] [[bbuugg]] _¶ │ │ │ │ │ Revised an internal change to the test system added as a result of _#_5_0_8_5 where │ │ │ │ │ a testing-related module per dialect would be loaded unconditionally upon │ │ │ │ │ making use of that dialect, pulling in SQLAlchemy’s testing framework as well │ │ │ │ │ as the ORM into the module import space. This would only impact initial startup │ │ │ │ │ time and memory to a modest extent, however it’s best that these additional │ │ │ │ │ modules aren’t reverse-dependent on straight Core usage. │ │ │ │ │ References: _#_5_1_8_0 │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_14.html │ │ │ │ @@ -3065,36 +3065,36 @@ │ │ │ │ attributes and entities that are installed as part of anInsert
,
│ │ │ │ Update
, or Delete
construct. The
│ │ │ │ Select.column_descriptions
accessor is also now implemented for
│ │ │ │ Core-only selectables.
│ │ │ │ References: #7861
│ │ │ │ │ │ │ │Fixed regression in “dynamic” loader strategy where the │ │ │ │ +
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
│ │ │ │ + │ │ │ │ +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
│ │ │ │ │ │ │ │Fixed bug where composite()
attributes would not work in
│ │ │ │ +
Fixed bug where composite()
attributes would not work in
│ │ │ │ conjunction with the selectin_polymorphic()
loader strategy for
│ │ │ │ joined table inheritance.
References: #7801
│ │ │ │ │ │ │ │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
│ │ │ │ - │ │ │ │ -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
│ │ │ │ │ │ │ │Added a CAST(VARCHAR2(128)) to the “table name”, “owner”, and other │ │ │ │ +
Added a CAST(VARCHAR2(128)) to the “table name”, “owner”, and other │ │ │ │ DDL-name parameters as used in reflection queries against Oracle system │ │ │ │ views such as ALL_TABLES, ALL_TAB_CONSTRAINTS, etc to better enable │ │ │ │ indexing to take place against these columns, as they previously would be │ │ │ │ implicitly handled as NVARCHAR2 due to Python’s use of Unicode for strings; │ │ │ │ these columns are documented in all Oracle versions as being VARCHAR2 with │ │ │ │ lengths varying from 30 to 128 characters depending on server version. │ │ │ │ Additionally, test support has been enabled for Unicode-named DDL │ │ │ │ @@ -5544,15 +5544,24 @@ │ │ │ │
Clarified the current purpose of the │ │ │ │ +
Fixed regression involving how the ORM would resolve a given mapped column │ │ │ │ +to a result row, where under cases such as joined eager loading, a slightly │ │ │ │ +more expensive “fallback” could take place to set up this resolution due to │ │ │ │ +some logic that was removed since 1.3. The issue could also cause │ │ │ │ +deprecation warnings involving column resolution to be emitted when using a │ │ │ │ +1.4 style query with joined eager loading.
│ │ │ │ +References: #6596
│ │ │ │ + │ │ │ │ +Clarified the current purpose of the
│ │ │ │ relationship.bake_queries
flag, which in 1.4 is to enable
│ │ │ │ or disable “lambda caching” of statements within the “lazyload” and
│ │ │ │ “selectinload” loader strategies; this is separate from the more
│ │ │ │ foundational SQL query cache that is used for most statements.
│ │ │ │ Additionally, the lazy loader no longer uses its own cache for many-to-one
│ │ │ │ SQL queries, which was an implementation quirk that doesn’t exist for any
│ │ │ │ other loader scenario. Finally, the “lru cache” warning that the lazyloader
│ │ │ │ @@ -5562,38 +5571,29 @@
│ │ │ │ setting bake_queries=False
for such a relationship will remove this
│ │ │ │ cache from being used, there’s no particular performance gain in this case
│ │ │ │ as using no caching vs. using a cache that needs to refresh often likely
│ │ │ │ still wins out on the caching being used side.
Adjusted the means by which classes such as scoped_session
│ │ │ │ +
Adjusted the means by which classes such as scoped_session
│ │ │ │ and AsyncSession
are generated from the base
│ │ │ │ Session
class, such that custom Session
│ │ │ │ subclasses such as that used by Flask-SQLAlchemy don’t need to implement
│ │ │ │ positional arguments when they call into the superclass method, and can
│ │ │ │ continue using the same argument styles as in previous releases.
References: #6285
│ │ │ │ │ │ │ │Fixed issue where query production for joinedload against a complex left │ │ │ │ +
Fixed issue where query production for joinedload against a complex left │ │ │ │ hand side involving joined-table inheritance could fail to produce a │ │ │ │ correct query, due to a clause adaption issue.
│ │ │ │References: #6595
│ │ │ │ │ │ │ │Fixed regression involving how the ORM would resolve a given mapped column │ │ │ │ -to a result row, where under cases such as joined eager loading, a slightly │ │ │ │ -more expensive “fallback” could take place to set up this resolution due to │ │ │ │ -some logic that was removed since 1.3. The issue could also cause │ │ │ │ -deprecation warnings involving column resolution to be emitted when using a │ │ │ │ -1.4 style query with joined eager loading.
│ │ │ │ -References: #6596
│ │ │ │ - │ │ │ │ -Fixed issue in experimental “select ORM objects from INSERT/UPDATE” use │ │ │ │ case where an error was raised if the statement were against a │ │ │ │ single-table-inheritance subclass.
│ │ │ │References: #6591
│ │ │ │ │ │ │ │The warning that’s emitted for relationship()
when multiple
│ │ │ │ @@ -6437,15 +6437,15 @@
│ │ │ │ synonyms can be established linking to these constructs which work
│ │ │ │ fully. This is a behavior that was semi-explicitly disallowed previously,
│ │ │ │ however since it did not fail in every scenario, explicit support
│ │ │ │ for assoc proxy and hybrids has been added.
References: #6267
│ │ │ │ │ │ │ │Fixed a critical performance issue where the traversal of a │ │ │ │ +
Fixed a critical performance issue where the traversal of a
│ │ │ │ select()
construct would traverse a repetitive product of the
│ │ │ │ represented FROM clauses as they were each referenced by columns in
│ │ │ │ the columns clause; for a series of nested subqueries with lots of columns
│ │ │ │ this could cause a large delay and significant memory growth. This
│ │ │ │ traversal is used by a wide variety of SQL and ORM functions, including by
│ │ │ │ the ORM Session
when it’s configured to have
│ │ │ │ “table-per-bind”, which while this is not a common use case, it seems to be
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -2032,31 +2032,31 @@
│ │ │ │ │ [[oorrmm]] [[uusseeccaassee]] _¶
│ │ │ │ │ Added new attributes _U_p_d_a_t_e_B_a_s_e_._r_e_t_u_r_n_i_n_g___c_o_l_u_m_n___d_e_s_c_r_i_p_t_i_o_n_s and
│ │ │ │ │ _U_p_d_a_t_e_B_a_s_e_._e_n_t_i_t_y___d_e_s_c_r_i_p_t_i_o_n to allow for inspection of ORM attributes and
│ │ │ │ │ entities that are installed as part of an _I_n_s_e_r_t, _U_p_d_a_t_e, or _D_e_l_e_t_e construct.
│ │ │ │ │ The _S_e_l_e_c_t_._c_o_l_u_m_n___d_e_s_c_r_i_p_t_i_o_n_s accessor is also now implemented for Core-only
│ │ │ │ │ selectables.
│ │ │ │ │ References: _#_7_8_6_1
│ │ │ │ │ +[[oorrmm]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] _¶
│ │ │ │ │ +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: _#_7_8_2_3
│ │ │ │ │ [[oorrmm]] [[bbuugg]] [[rreeggrreessssiioonn]] _¶
│ │ │ │ │ Fixed regression in “dynamic” loader strategy where the _Q_u_e_r_y_._f_i_l_t_e_r___b_y_(_)
│ │ │ │ │ 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: _#_7_8_6_8
│ │ │ │ │ [[oorrmm]] [[bbuugg]] _¶
│ │ │ │ │ Fixed bug where _c_o_m_p_o_s_i_t_e_(_) attributes would not work in conjunction with the
│ │ │ │ │ _s_e_l_e_c_t_i_n___p_o_l_y_m_o_r_p_h_i_c_(_) loader strategy for joined table inheritance.
│ │ │ │ │ References: _#_7_8_0_1
│ │ │ │ │ -[[oorrmm]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] _¶
│ │ │ │ │ -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: _#_7_8_2_3
│ │ │ │ │ [[oorrmm]] [[bbuugg]] _¶
│ │ │ │ │ Fixed issue where the _s_e_l_e_c_t_i_n___p_o_l_y_m_o_r_p_h_i_c_(_) 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: _#_7_7_9_9
│ │ │ │ │ [[oorrmm]] [[bbuugg]] _¶
│ │ │ │ │ @@ -3255,15 +3255,15 @@
│ │ │ │ │ * [[mmssssqqll]] [[bbuugg]] [[rreefflleeccttiioonn]] _¶
│ │ │ │ │ Fixed an issue where sqlalchemy.engine.reflection.has_table() returned
│ │ │ │ │ True for local temporary tables that actually belonged to a different SQL
│ │ │ │ │ Server session (connection). An extra check is now performed to ensure
│ │ │ │ │ that the temp table detected is in fact owned by the current session.
│ │ │ │ │ References: _#_6_9_1_0
│ │ │ │ │ ******** oorraaccllee_?¶ ********
│ │ │ │ │ - * [[oorraaccllee]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] _¶
│ │ │ │ │ + * [[oorraaccllee]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] _¶
│ │ │ │ │ Added a CAST(VARCHAR2(128)) to the “table name”, “owner”, and other DDL-
│ │ │ │ │ name parameters as used in reflection queries against Oracle system views
│ │ │ │ │ such as ALL_TABLES, ALL_TAB_CONSTRAINTS, etc to better enable indexing to
│ │ │ │ │ take place against these columns, as they previously would be implicitly
│ │ │ │ │ handled as NVARCHAR2 due to Python’s use of Unicode for strings; these
│ │ │ │ │ columns are documented in all Oracle versions as being VARCHAR2 with
│ │ │ │ │ lengths varying from 30 to 128 characters depending on server version.
│ │ │ │ │ @@ -3763,51 +3763,50 @@
│ │ │ │ │ the INSERT thus triggering SQLAlchemy’s feature of setting IDENTITY INSERT to
│ │ │ │ │ “on”; it’s in this directive where the schema translate map would fail to be
│ │ │ │ │ honored.
│ │ │ │ │ References: _#_6_6_5_8
│ │ │ │ │ ********** 11..44..1188_?¶ **********
│ │ │ │ │ Released: June 10, 2021
│ │ │ │ │ ******** oorrmm_?¶ ********
│ │ │ │ │ - * [[oorrmm]] [[bbuugg]] _¶
│ │ │ │ │ - Clarified the current purpose of the _r_e_l_a_t_i_o_n_s_h_i_p_._b_a_k_e___q_u_e_r_i_e_s flag,
│ │ │ │ │ - which in 1.4 is to enable or disable “lambda caching” of statements
│ │ │ │ │ - within the “lazyload” and “selectinload” loader strategies; this is
│ │ │ │ │ - separate from the more foundational SQL query cache that is used for most
│ │ │ │ │ - statements. Additionally, the lazy loader no longer uses its own cache
│ │ │ │ │ - for many-to-one SQL queries, which was an implementation quirk that
│ │ │ │ │ - doesn’t exist for any other loader scenario. Finally, the “lru cache”
│ │ │ │ │ - warning that the lazyloader and selectinloader strategies could emit when
│ │ │ │ │ - handling a wide array of class/relationship combinations has been
│ │ │ │ │ - removed; based on analysis of some end-user cases, this warning doesn’t
│ │ │ │ │ - suggest any significant issue. While setting bake_queries=False for such
│ │ │ │ │ - a relationship will remove this cache from being used, there’s no
│ │ │ │ │ - particular performance gain in this case as using no caching vs. using a
│ │ │ │ │ - cache that needs to refresh often likely still wins out on the caching
│ │ │ │ │ - being used side.
│ │ │ │ │ - References: _#_6_0_7_2, _#_6_4_8_7
│ │ │ │ │ + * [[oorrmm]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] [[rreeggrreessssiioonn]] _¶
│ │ │ │ │ + Fixed regression involving how the ORM would resolve a given mapped
│ │ │ │ │ + column to a result row, where under cases such as joined eager loading, a
│ │ │ │ │ + slightly more expensive “fallback” could take place to set up this
│ │ │ │ │ + resolution due to some logic that was removed since 1.3. The issue could
│ │ │ │ │ + also cause deprecation warnings involving column resolution to be emitted
│ │ │ │ │ + when using a 1.4 style query with joined eager loading.
│ │ │ │ │ + References: _#_6_5_9_6
│ │ │ │ │ +[[oorrmm]] [[bbuugg]] _¶
│ │ │ │ │ +Clarified the current purpose of the _r_e_l_a_t_i_o_n_s_h_i_p_._b_a_k_e___q_u_e_r_i_e_s flag, which in
│ │ │ │ │ +1.4 is to enable or disable “lambda caching” of statements within the
│ │ │ │ │ +“lazyload” and “selectinload” loader strategies; this is separate from the more
│ │ │ │ │ +foundational SQL query cache that is used for most statements. Additionally,
│ │ │ │ │ +the lazy loader no longer uses its own cache for many-to-one SQL queries, which
│ │ │ │ │ +was an implementation quirk that doesn’t exist for any other loader scenario.
│ │ │ │ │ +Finally, the “lru cache” warning that the lazyloader and selectinloader
│ │ │ │ │ +strategies could emit when handling a wide array of class/relationship
│ │ │ │ │ +combinations has been removed; based on analysis of some end-user cases, this
│ │ │ │ │ +warning doesn’t suggest any significant issue. While setting bake_queries=False
│ │ │ │ │ +for such a relationship will remove this cache from being used, there’s no
│ │ │ │ │ +particular performance gain in this case as using no caching vs. using a cache
│ │ │ │ │ +that needs to refresh often likely still wins out on the caching being used
│ │ │ │ │ +side.
│ │ │ │ │ +References: _#_6_0_7_2, _#_6_4_8_7
│ │ │ │ │ [[oorrmm]] [[bbuugg]] [[rreeggrreessssiioonn]] _¶
│ │ │ │ │ Adjusted the means by which classes such as _s_c_o_p_e_d___s_e_s_s_i_o_n and _A_s_y_n_c_S_e_s_s_i_o_n are
│ │ │ │ │ generated from the base _S_e_s_s_i_o_n class, such that custom _S_e_s_s_i_o_n subclasses such
│ │ │ │ │ as that used by Flask-SQLAlchemy don’t need to implement positional arguments
│ │ │ │ │ when they call into the superclass method, and can continue using the same
│ │ │ │ │ argument styles as in previous releases.
│ │ │ │ │ References: _#_6_2_8_5
│ │ │ │ │ [[oorrmm]] [[bbuugg]] [[rreeggrreessssiioonn]] _¶
│ │ │ │ │ Fixed issue where query production for joinedload against a complex left hand
│ │ │ │ │ side involving joined-table inheritance could fail to produce a correct query,
│ │ │ │ │ due to a clause adaption issue.
│ │ │ │ │ References: _#_6_5_9_5
│ │ │ │ │ -[[oorrmm]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] [[rreeggrreessssiioonn]] _¶
│ │ │ │ │ -Fixed regression involving how the ORM would resolve a given mapped column to a
│ │ │ │ │ -result row, where under cases such as joined eager loading, a slightly more
│ │ │ │ │ -expensive “fallback” could take place to set up this resolution due to some
│ │ │ │ │ -logic that was removed since 1.3. The issue could also cause deprecation
│ │ │ │ │ -warnings involving column resolution to be emitted when using a 1.4 style query
│ │ │ │ │ -with joined eager loading.
│ │ │ │ │ -References: _#_6_5_9_6
│ │ │ │ │ [[oorrmm]] [[bbuugg]] _¶
│ │ │ │ │ Fixed issue in experimental “select ORM objects from INSERT/UPDATE” use case
│ │ │ │ │ where an error was raised if the statement were against a single-table-
│ │ │ │ │ inheritance subclass.
│ │ │ │ │ References: _#_6_5_9_1
│ │ │ │ │ [[oorrmm]] [[bbuugg]] _¶
│ │ │ │ │ The warning that’s emitted for _r_e_l_a_t_i_o_n_s_h_i_p_(_) when multiple relationships would
│ │ │ │ │ @@ -4377,15 +4376,15 @@
│ │ │ │ │ Established support for synoynm() in conjunction with hybrid property,
│ │ │ │ │ assocaitionproxy is set up completely, including that synonyms can be
│ │ │ │ │ established linking to these constructs which work fully. This is a
│ │ │ │ │ behavior that was semi-explicitly disallowed previously, however since it
│ │ │ │ │ did not fail in every scenario, explicit support for assoc proxy and
│ │ │ │ │ hybrids has been added.
│ │ │ │ │ References: _#_6_2_6_7
│ │ │ │ │ -[[oorrmm]] [[bbuugg]] [[ppeerrffoorrmmaannccee]] [[rreeggrreessssiioonn]] [[ssqqll]] _¶
│ │ │ │ │ +[[oorrmm]] [[ppeerrffoorrmmaannccee]] [[bbuugg]] [[rreeggrreessssiioonn]] [[ssqqll]] _¶
│ │ │ │ │ Fixed a critical performance issue where the traversal of a _s_e_l_e_c_t_(_) construct
│ │ │ │ │ would traverse a repetitive product of the represented FROM clauses as they
│ │ │ │ │ were each referenced by columns in the columns clause; for a series of nested
│ │ │ │ │ subqueries with lots of columns this could cause a large delay and significant
│ │ │ │ │ memory growth. This traversal is used by a wide variety of SQL and ORM
│ │ │ │ │ functions, including by the ORM _S_e_s_s_i_o_n when it’s configured to have “table-
│ │ │ │ │ per-bind”, which while this is not a common use case, it seems to be what
│ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_20.html
│ │ │ │ @@ -1573,32 +1573,32 @@
│ │ │ │
Fixed regression caused by #9779 where using the “secondary” table
│ │ │ │ -in a relationship and_()
expression would fail to be aliased to match
│ │ │ │ -how the “secondary” table normally renders within a
│ │ │ │ -Select.join()
expression, leading to an invalid query.
References: #11010
│ │ │ │ - │ │ │ │ -Adjusted the fix made in #10570, released in 2.0.23, where new │ │ │ │ +
Adjusted the fix made in #10570, released in 2.0.23, where new
│ │ │ │ logic was added to reconcile possibly changing bound parameter values
│ │ │ │ across cache key generations used within the with_expression()
│ │ │ │ construct. The new logic changes the approach by which the new bound
│ │ │ │ parameter values are associated with the statement, avoiding the need to
│ │ │ │ deep-copy the statement which can result in a significant performance
│ │ │ │ penalty for very deep / complex SQL constructs. The new approach no longer
│ │ │ │ requires this deep-copy step.
References: #11085
│ │ │ │ │ │ │ │Fixed regression caused by #9779 where using the “secondary” table
│ │ │ │ +in a relationship and_()
expression would fail to be aliased to match
│ │ │ │ +how the “secondary” table normally renders within a
│ │ │ │ +Select.join()
expression, leading to an invalid query.
References: #11010
│ │ │ │ + │ │ │ │ +Added new core execution option
│ │ │ │ Connection.execution_options.preserve_rowcount
. When
│ │ │ │ @@ -1831,15 +1831,15 @@
│ │ │ │
Changed the default arraysize of the Oracle dialects so that the value set │ │ │ │ +
Changed the default arraysize of the Oracle dialects so that the value set │ │ │ │ by the driver is used, that is 100 at the time of writing for both │ │ │ │ cx_oracle and oracledb. Previously the value was set to 50 by default. The │ │ │ │ setting of 50 could cause significant performance regressions compared to │ │ │ │ when using cx_oracle/oracledb alone to fetch many hundreds of rows over │ │ │ │ slower networks.
│ │ │ │References: #10877
│ │ │ │ │ │ │ │ @@ -6073,39 +6073,39 @@ │ │ │ │relationship()
etc. to provide for the Python dataclasses
│ │ │ │ compare
parameter on field()
, when using the
│ │ │ │ Declarative Dataclass Mapping feature. Pull request courtesy
│ │ │ │ Simon Schiele.
│ │ │ │ References: #8905
│ │ │ │ │ │ │ │Fixed issue where use of an unknown datatype within a Mapped
│ │ │ │ +
Additional performance enhancements within ORM-enabled SQL statements,
│ │ │ │ +specifically targeting callcounts within the construction of ORM
│ │ │ │ +statements, using combinations of aliased()
with
│ │ │ │ +union()
and similar “compound” constructs, in addition to direct
│ │ │ │ +performance improvements to the corresponding_column()
internal method
│ │ │ │ +that is used heavily by the ORM by constructs like aliased()
and
│ │ │ │ +similar.
References: #8796
│ │ │ │ + │ │ │ │ +Fixed issue where use of an unknown datatype within a Mapped
│ │ │ │ annotation for a column-based attribute would silently fail to map the
│ │ │ │ attribute, rather than reporting an exception; an informative exception
│ │ │ │ message is now raised.
References: #8888
│ │ │ │ │ │ │ │Fixed a suite of issues involving Mapped
use with dictionary
│ │ │ │ +
Fixed a suite of issues involving Mapped
use with dictionary
│ │ │ │ types, such as Mapped[Dict[str, str] | None]
, would not be correctly
│ │ │ │ interpreted in Declarative ORM mappings. Support to correctly
│ │ │ │ “de-optionalize” this type including for lookup in type_annotation_map
│ │ │ │ has been fixed.
References: #8777
│ │ │ │ │ │ │ │Additional performance enhancements within ORM-enabled SQL statements,
│ │ │ │ -specifically targeting callcounts within the construction of ORM
│ │ │ │ -statements, using combinations of aliased()
with
│ │ │ │ -union()
and similar “compound” constructs, in addition to direct
│ │ │ │ -performance improvements to the corresponding_column()
internal method
│ │ │ │ -that is used heavily by the ORM by constructs like aliased()
and
│ │ │ │ -similar.
References: #8796
│ │ │ │ - │ │ │ │ -Fixed bug in Declarative Dataclass Mapping feature where using
│ │ │ │ plain dataclass fields with the __allow_unmapped__
directive in a
│ │ │ │ mapping would not create a dataclass with the correct class-level state for
│ │ │ │ those fields, copying the raw Field
object to the class inappropriately
│ │ │ │ after dataclasses itself had replaced the Field
object with the
│ │ │ │ class-level default value.
References: #8880
│ │ │ │ @@ -7952,15 +7952,29 @@ │ │ │ │ that may refer to additional tables within the WHERE criteria of the │ │ │ │ statement without the need to use subqueries. This syntax is invoked │ │ │ │ automatically when using theUpdate
construct when more than
│ │ │ │ one table or other entity or selectable is used.
│ │ │ │ References: #7185
│ │ │ │ │ │ │ │Removed the warning that emits from the Numeric
type about
│ │ │ │ +
The SQLite dialect now defaults to QueuePool
when a file
│ │ │ │ +based database is used. This is set along with setting the
│ │ │ │ +check_same_thread
parameter to False
. It has been observed that the
│ │ │ │ +previous approach of defaulting to NullPool
, which does not
│ │ │ │ +hold onto database connections after they are released, did in fact have a
│ │ │ │ +measurable negative performance impact. As always, the pool class is
│ │ │ │ +customizable via the create_engine.poolclass
parameter.
See also
│ │ │ │ + │ │ │ │ +References: #7490
│ │ │ │ + │ │ │ │ +Removed the warning that emits from the Numeric
type about
│ │ │ │ DBAPIs not supporting Decimal values natively. This warning was oriented
│ │ │ │ towards SQLite, which does not have any real way without additional
│ │ │ │ extensions or workarounds of handling precision numeric values more than 15
│ │ │ │ significant digits as it only uses floating point math to represent
│ │ │ │ numbers. As this is a known and documented limitation in SQLite itself, and
│ │ │ │ not a quirk of the pysqlite driver, there’s no need for SQLAlchemy to warn
│ │ │ │ for this. The change does not otherwise modify how precision numerics are
│ │ │ │ @@ -7968,28 +7982,14 @@
│ │ │ │ as configured with the Numeric
, Float
, and
│ │ │ │ related datatypes, just without the ability to maintain precision beyond 15
│ │ │ │ significant digits when using SQLite, unless alternate representations such
│ │ │ │ as strings are used.
References: #7299
│ │ │ │ │ │ │ │The SQLite dialect now defaults to QueuePool
when a file
│ │ │ │ -based database is used. This is set along with setting the
│ │ │ │ -check_same_thread
parameter to False
. It has been observed that the
│ │ │ │ -previous approach of defaulting to NullPool
, which does not
│ │ │ │ -hold onto database connections after they are released, did in fact have a
│ │ │ │ -measurable negative performance impact. As always, the pool class is
│ │ │ │ -customizable via the create_engine.poolclass
parameter.
See also
│ │ │ │ - │ │ │ │ -References: #7490
│ │ │ │ - │ │ │ │ -Implemented reflection of the “clustered index” flag mssql_clustered
│ │ │ │ for the SQL Server dialect. Pull request courtesy John Lennox.