{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.bkga9gKY/b1/sqlalchemy_2.0.32+ds1-1_arm64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.bkga9gKY/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- 0465d3d23c9e93e88023f8f7f379d8a5 3956248 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb\n+ d946d1ceb5fa061be74f2b109714fbb5 3956232 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb\n e28bf22ee46612c2b78a4b070ce23e4d 886724 debug optional python3-sqlalchemy-ext-dbgsym_2.0.32+ds1-1_arm64.deb\n 597ecc0a6120f50638232e16a30320b6 123580 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 13904 2024-08-23 07:52:58.000000 control.tar.xz\n--rw-r--r-- 0 0 0 3942152 2024-08-23 07:52:58.000000 data.tar.xz\n+-rw-r--r-- 0 0 0 3942136 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_14.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_14.html", "unified_diff": "@@ -9239,22 +9239,15 @@\n
\n

See also

\n

RowProxy is no longer a \u201cproxy\u201d; is now called Row and behaves like an enhanced named tuple

\n
\n

References: #4710

\n

\n \n-
  • [engine] [performance] \u00b6

    The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n-connection that was just opened in the same checkout operation. pre ping\n-only applies to a DBAPI connection that\u2019s been checked into the pool\n-and is being checked out again.

    \n-

    References: #4524

    \n-

    \n-
  • \n-
  • [engine] [performance] [change] [py3k] \u00b6

    Disabled the \u201cunicode returns\u201d check that runs on dialect startup when\n+

  • [engine] [change] [performance] [py3k] \u00b6

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

    \n

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

    \n

    References: #5315

    \n

    \n
  • \n+
  • [engine] [performance] \u00b6

    The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n+connection that was just opened in the same checkout operation. pre ping\n+only applies to a DBAPI connection that\u2019s been checked into the pool\n+and is being checked out again.

    \n+

    References: #4524

    \n+

    \n+
  • \n
  • [engine] [bug] \u00b6

    Revised the Connection.execution_options.schema_translate_map\n feature such that the processing of the SQL statement to receive a specific\n schema name occurs within the execution phase of the statement, rather than\n at the compile phase. This is to support the statement being efficiently\n cached. Previously, the current schema being rendered into the statement\n for a particular run would be considered as part of the cache key itself,\n meaning that for a run against hundreds of schemas, there would be hundreds\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -6355,21 +6355,15 @@\n returned by the ResultProxy is now the LegacyRow subclass, which maintains\n mapping/tuple hybrid behavior, however the base _\bR_\bo_\bw class now behaves more\n fully like a named tuple.\n See also\n _\bR_\bo_\bw_\bP_\br_\bo_\bx_\by_\b _\bi_\bs_\b _\bn_\bo_\b _\bl_\bo_\bn_\bg_\be_\br_\b _\ba_\b _\b\u201c_\bp_\br_\bo_\bx_\by_\b\u201d_\b;_\b _\bi_\bs_\b _\bn_\bo_\bw_\b _\bc_\ba_\bl_\bl_\be_\bd_\b _\bR_\bo_\bw_\b _\ba_\bn_\bd_\b _\bb_\be_\bh_\ba_\bv_\be_\bs_\b _\bl_\bi_\bk_\be_\b _\ba_\bn_\b _\be_\bn_\bh_\ba_\bn_\bc_\be_\bd\n _\bn_\ba_\bm_\be_\bd_\b _\bt_\bu_\bp_\bl_\be\n References: _\b#_\b4_\b7_\b1_\b0\n-[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n-The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n-connection that was just opened in the same checkout operation. pre ping only\n-applies to a DBAPI connection that\u2019s been checked into the pool and is being\n-checked out again.\n-References: _\b#_\b4_\b5_\b2_\b4\n-[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[c\bch\bha\ban\bng\bge\be]\b] [\b[p\bpy\by3\b3k\bk]\b] _\b\u00b6\n+[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[c\bch\bha\ban\bng\bge\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[p\bpy\by3\b3k\bk]\b] _\b\u00b6\n Disabled the \u201cunicode returns\u201d check that runs on dialect startup when running\n under Python 3, which for many years has occurred in order to test the current\n DBAPI\u2019s behavior for whether or not it returns Python Unicode or Py2K strings\n for the VARCHAR and NVARCHAR datatypes. The check still occurs by default under\n Python 2, however the mechanism to test the behavior will be removed in\n SQLAlchemy 2.0 when Python 2 support is also removed.\n This logic was very effective when it was needed, however now that Python 3 is\n@@ -6377,14 +6371,20 @@\n datatypes. In the unlikely case that a third party DBAPI does not support this,\n the conversion logic within _\bS_\bt_\br_\bi_\bn_\bg is still available and the third party\n dialect may specify this in its upfront dialect flags by setting the dialect\n level flag returns_unicode_strings to one of String.RETURNS_CONDITIONAL or\n String.RETURNS_BYTES, both of which will enable Unicode conversion even under\n Python 3.\n References: _\b#_\b5_\b3_\b1_\b5\n+[\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n+The pool \u201cpre-ping\u201d feature has been refined to not invoke for a DBAPI\n+connection that was just opened in the same checkout operation. pre ping only\n+applies to a DBAPI connection that\u2019s been checked into the pool and is being\n+checked out again.\n+References: _\b#_\b4_\b5_\b2_\b4\n [\b[e\ben\bng\bgi\bin\bne\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Revised the _\bC_\bo_\bn_\bn_\be_\bc_\bt_\bi_\bo_\bn_\b._\be_\bx_\be_\bc_\bu_\bt_\bi_\bo_\bn_\b__\bo_\bp_\bt_\bi_\bo_\bn_\bs_\b._\bs_\bc_\bh_\be_\bm_\ba_\b__\bt_\br_\ba_\bn_\bs_\bl_\ba_\bt_\be_\b__\bm_\ba_\bp feature such that\n the processing of the SQL statement to receive a specific schema name occurs\n within the execution phase of the statement, rather than at the compile phase.\n This is to support the statement being efficiently cached. Previously, the\n current schema being rendered into the statement for a particular run would be\n considered as part of the cache key itself, meaning that for a run against\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": "@@ -7935,31 +7935,31 @@\n

    \n
  • \n
  • [sqlite] [usecase] \u00b6

    Added RETURNING support for the SQLite dialect. SQLite supports RETURNING\n since version 3.35.

    \n

    References: #6195

    \n

    \n
  • \n-
  • [sqlite] [usecase] \u00b6

    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.

    \n-

    References: #7185

    \n-

    \n-
  • \n-
  • [sqlite] [performance] [usecase] \u00b6

    SQLite datetime, date, and time datatypes now use Python standard lib\n+

  • [sqlite] [usecase] [performance] \u00b6

    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.

    \n

    References: #7029

    \n

    \n
  • \n+
  • [sqlite] [usecase] \u00b6

    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.

    \n+

    References: #7185

    \n+

    \n+
  • \n
  • [sqlite] [bug] \u00b6

    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", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -5471,29 +5471,29 @@\n See also\n _\bR_\be_\bf_\bl_\be_\bc_\bt_\bi_\bn_\bg_\b _\bi_\bn_\bt_\be_\br_\bn_\ba_\bl_\b _\bs_\bc_\bh_\be_\bm_\ba_\b _\bt_\ba_\bb_\bl_\be_\bs\n References: _\b#_\b8_\b2_\b3_\b4\n [\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n Added RETURNING support for the SQLite dialect. SQLite supports RETURNING since\n version 3.35.\n References: _\b#_\b6_\b1_\b9_\b5\n-[\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n-The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements that\n-may refer to additional tables within the WHERE criteria of the statement\n-without the need to use subqueries. This syntax is invoked automatically when\n-using the _\bU_\bp_\bd_\ba_\bt_\be construct when more than one table or other entity or\n-selectable is used.\n-References: _\b#_\b7_\b1_\b8_\b5\n-[\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n+[\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] [\b[p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be]\b] _\b\u00b6\n SQLite datetime, date, and time datatypes now use Python standard lib\n fromisoformat() methods in order to parse incoming datetime, date, and time\n string values. This improves performance vs. the previous regular expression-\n based approach, and also automatically accommodates for datetime and time\n formats that contain either a six-digit \u201cmicroseconds\u201d format or a three-digit\n \u201cmilliseconds\u201d format.\n References: _\b#_\b7_\b0_\b2_\b9\n+[\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[u\bus\bse\bec\bca\bas\bse\be]\b] _\b\u00b6\n+The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements that\n+may refer to additional tables within the WHERE criteria of the statement\n+without the need to use subqueries. This syntax is invoked automatically when\n+using the _\bU_\bp_\bd_\ba_\bt_\be construct when more than one table or other entity or\n+selectable is used.\n+References: _\b#_\b7_\b1_\b8_\b5\n [\b[s\bsq\bql\bli\bit\bte\be]\b] [\b[b\bbu\bug\bg]\b] _\b\u00b6\n Removed the warning that emits from the _\bN_\bu_\bm_\be_\br_\bi_\bc type about DBAPIs not\n supporting Decimal values natively. This warning was oriented towards SQLite,\n which does not have any real way without additional extensions or workarounds\n of handling precision numeric values more than 15 significant digits as it only\n uses floating point math to represent numbers. As this is a known and\n documented limitation in SQLite itself, and not a quirk of the pysqlite driver,\n"}]}]}]}]}]}