--- /srv/rebuilderd/tmp/rebuilderdETM2Ab/inputs/python-sqlalchemy-doc_2.0.48+ds1-1_all.deb +++ /srv/rebuilderd/tmp/rebuilderdETM2Ab/out/python-sqlalchemy-doc_2.0.48+ds1-1_all.deb ├── file list │ @@ -1,3 +1,3 @@ │ -rw-r--r-- 0 0 0 4 2026-03-26 16:21:23.000000 debian-binary │ -rw-r--r-- 0 0 0 13772 2026-03-26 16:21:23.000000 control.tar.xz │ --rw-r--r-- 0 0 0 4024268 2026-03-26 16:21:23.000000 data.tar.xz │ +-rw-r--r-- 0 0 0 4024152 2026-03-26 16:21:23.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,15 +9314,22 @@ │ │ │
│ │ │

See also

│ │ │

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

│ │ │
│ │ │

References: #4710

│ │ │

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

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

  • [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 │ │ │ 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 │ │ │ @@ -9333,21 +9340,14 @@ │ │ │ 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,15 +6406,21 @@ │ │ │ │ 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]] [[cchhaannggee]] [[ppeerrffoorrmmaannccee]] [[ppyy33kk]] _¶ │ │ │ │ +[[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]] _¶ │ │ │ │ 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 │ │ │ │ @@ -6422,20 +6428,14 @@ │ │ │ │ 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