--- /srv/reproducible-results/rbuild-debian/r-b-build.G01hcOGf/b1/sqlalchemy_2.0.40+ds1-1_arm64.changes +++ /srv/reproducible-results/rbuild-debian/r-b-build.G01hcOGf/b2/sqlalchemy_2.0.40+ds1-1_arm64.changes ├── Files │ @@ -1,5 +1,5 @@ │ │ - e5f85bc43bc02a07ccd4ce3e9a456976 3987524 doc optional python-sqlalchemy-doc_2.0.40+ds1-1_all.deb │ + 0482ab744c2872c4afcbfc49afee7b25 3987696 doc optional python-sqlalchemy-doc_2.0.40+ds1-1_all.deb │ dc4c91cc2b655432ad954dcef7cc5f01 914832 debug optional python3-sqlalchemy-ext-dbgsym_2.0.40+ds1-1_arm64.deb │ 2accbd38aa63464d6d63c39848949c0d 135352 python optional python3-sqlalchemy-ext_2.0.40+ds1-1_arm64.deb │ 06b6365d77f51caac8542c94ebe1ba72 1210228 python optional python3-sqlalchemy_2.0.40+ds1-1_all.deb ├── python-sqlalchemy-doc_2.0.40+ds1-1_all.deb │ ├── file list │ │ @@ -1,3 +1,3 @@ │ │ -rw-r--r-- 0 0 0 4 2025-02-06 11:19:07.000000 debian-binary │ │ --rw-r--r-- 0 0 0 13680 2025-02-06 11:19:07.000000 control.tar.xz │ │ --rw-r--r-- 0 0 0 3973652 2025-02-06 11:19:07.000000 data.tar.xz │ │ +-rw-r--r-- 0 0 0 13684 2025-02-06 11:19:07.000000 control.tar.xz │ │ +-rw-r--r-- 0 0 0 3973820 2025-02-06 11:19:07.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_14.html │ │ │ │ @@ -9314,22 +9314,15 @@ │ │ │ │
│ │ │ │

See also

│ │ │ │

RowProxy is no longer a “proxy”; is now called Row and behaves like an enhanced named tuple

│ │ │ │
│ │ │ │

References: #4710

│ │ │ │

│ │ │ │ │ │ │ │ -
  • [engine] [performance]

    The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ -connection that was just opened in the same checkout operation. pre ping │ │ │ │ -only applies to a DBAPI connection that’s been checked into the pool │ │ │ │ -and is being checked out again.

    │ │ │ │ -

    References: #4524

    │ │ │ │ -

    │ │ │ │ -
  • │ │ │ │ -
  • [engine] [performance] [change] [py3k]

    Disabled the “unicode returns” check that runs on dialect startup when │ │ │ │ +

  • [engine] [change] [performance] [py3k]

    Disabled the “unicode returns” check that runs on dialect startup when │ │ │ │ running under Python 3, which for many years has occurred in order to test │ │ │ │ the current DBAPI’s behavior for whether or not it returns Python Unicode │ │ │ │ or Py2K strings for the VARCHAR and NVARCHAR datatypes. The check still │ │ │ │ occurs by default under Python 2, however the mechanism to test the │ │ │ │ behavior will be removed in SQLAlchemy 2.0 when Python 2 support is also │ │ │ │ removed.

    │ │ │ │

    This logic was very effective when it was needed, however now that Python 3 │ │ │ │ @@ -9340,14 +9333,21 @@ │ │ │ │ dialect flags by setting the dialect level flag returns_unicode_strings │ │ │ │ to one of String.RETURNS_CONDITIONAL or │ │ │ │ String.RETURNS_BYTES, both of which will enable Unicode conversion │ │ │ │ even under Python 3.

    │ │ │ │

    References: #5315

    │ │ │ │

    │ │ │ │
  • │ │ │ │ +
  • [engine] [performance]

    The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ +connection that was just opened in the same checkout operation. pre ping │ │ │ │ +only applies to a DBAPI connection that’s been checked into the pool │ │ │ │ +and is being checked out again.

    │ │ │ │ +

    References: #4524

    │ │ │ │ +

    │ │ │ │ +
  • │ │ │ │
  • [engine] [bug]

    Revised the Connection.execution_options.schema_translate_map │ │ │ │ feature such that the processing of the SQL statement to receive a specific │ │ │ │ schema name occurs within the execution phase of the statement, rather than │ │ │ │ at the compile phase. This is to support the statement being efficiently │ │ │ │ cached. Previously, the current schema being rendered into the statement │ │ │ │ for a particular run would be considered as part of the cache key itself, │ │ │ │ meaning that for a run against hundreds of schemas, there would be hundreds │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -6406,21 +6406,15 @@ │ │ │ │ │ returned by the ResultProxy is now the LegacyRow subclass, which maintains │ │ │ │ │ mapping/tuple hybrid behavior, however the base _R_o_w class now behaves more │ │ │ │ │ fully like a named tuple. │ │ │ │ │ See also │ │ │ │ │ _R_o_w_P_r_o_x_y_ _i_s_ _n_o_ _l_o_n_g_e_r_ _a_ _“_p_r_o_x_y_”_;_ _i_s_ _n_o_w_ _c_a_l_l_e_d_ _R_o_w_ _a_n_d_ _b_e_h_a_v_e_s_ _l_i_k_e_ _a_n_ _e_n_h_a_n_c_e_d │ │ │ │ │ _n_a_m_e_d_ _t_u_p_l_e │ │ │ │ │ References: _#_4_7_1_0 │ │ │ │ │ -[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] _¶ │ │ │ │ │ -The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ │ -connection that was just opened in the same checkout operation. pre ping only │ │ │ │ │ -applies to a DBAPI connection that’s been checked into the pool and is being │ │ │ │ │ -checked out again. │ │ │ │ │ -References: _#_4_5_2_4 │ │ │ │ │ -[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] [[cchhaannggee]] [[ppyy33kk]] _¶ │ │ │ │ │ +[[eennggiinnee]] [[cchhaannggee]] [[ppeerrffoorrmmaannccee]] [[ppyy33kk]] _¶ │ │ │ │ │ Disabled the “unicode returns” check that runs on dialect startup when running │ │ │ │ │ under Python 3, which for many years has occurred in order to test the current │ │ │ │ │ DBAPI’s behavior for whether or not it returns Python Unicode or Py2K strings │ │ │ │ │ for the VARCHAR and NVARCHAR datatypes. The check still occurs by default under │ │ │ │ │ Python 2, however the mechanism to test the behavior will be removed in │ │ │ │ │ SQLAlchemy 2.0 when Python 2 support is also removed. │ │ │ │ │ This logic was very effective when it was needed, however now that Python 3 is │ │ │ │ │ @@ -6428,14 +6422,20 @@ │ │ │ │ │ datatypes. In the unlikely case that a third party DBAPI does not support this, │ │ │ │ │ the conversion logic within _S_t_r_i_n_g is still available and the third party │ │ │ │ │ dialect may specify this in its upfront dialect flags by setting the dialect │ │ │ │ │ level flag returns_unicode_strings to one of String.RETURNS_CONDITIONAL or │ │ │ │ │ String.RETURNS_BYTES, both of which will enable Unicode conversion even under │ │ │ │ │ Python 3. │ │ │ │ │ References: _#_5_3_1_5 │ │ │ │ │ +[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] _¶ │ │ │ │ │ +The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ │ +connection that was just opened in the same checkout operation. pre ping only │ │ │ │ │ +applies to a DBAPI connection that’s been checked into the pool and is being │ │ │ │ │ +checked out again. │ │ │ │ │ +References: _#_4_5_2_4 │ │ │ │ │ [[eennggiinnee]] [[bbuugg]] _¶ │ │ │ │ │ Revised the _C_o_n_n_e_c_t_i_o_n_._e_x_e_c_u_t_i_o_n___o_p_t_i_o_n_s_._s_c_h_e_m_a___t_r_a_n_s_l_a_t_e___m_a_p feature such that │ │ │ │ │ the processing of the SQL statement to receive a specific schema name occurs │ │ │ │ │ within the execution phase of the statement, rather than at the compile phase. │ │ │ │ │ This is to support the statement being efficiently cached. Previously, the │ │ │ │ │ current schema being rendered into the statement for a particular run would be │ │ │ │ │ considered as part of the cache key itself, meaning that for a run against