--- /srv/reproducible-results/rbuild-debian/r-b-build.9JEM4O51/b1/sqlalchemy_1.4.50+ds1-1_amd64.changes +++ /srv/reproducible-results/rbuild-debian/r-b-build.9JEM4O51/b2/sqlalchemy_1.4.50+ds1-1_amd64.changes ├── Files │ @@ -1,5 +1,5 @@ │ │ - 3f67245a2ffb1f76d0a6e36142d10a7b 3720016 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb │ + 739570e234d53bb198d30e333edf17f5 3720044 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb │ 5644a5f4007e027d67a7e9c2152c87e8 70312 debug optional python3-sqlalchemy-ext-dbgsym_1.4.50+ds1-1_amd64.deb │ 43fb1fe4a0a459ee6c85e9a9d5ed8dcc 20916 python optional python3-sqlalchemy-ext_1.4.50+ds1-1_amd64.deb │ 7b9b7746123a45060be2c12bd6e80ed4 1009400 python optional python3-sqlalchemy_1.4.50+ds1-1_all.deb ├── python-sqlalchemy-doc_1.4.50+ds1-1_all.deb │ ├── file list │ │ @@ -1,3 +1,3 @@ │ │ -rw-r--r-- 0 0 0 4 2024-01-05 13:47:47.000000 debian-binary │ │ --rw-r--r-- 0 0 0 13376 2024-01-05 13:47:47.000000 control.tar.xz │ │ --rw-r--r-- 0 0 0 3706448 2024-01-05 13:47:47.000000 data.tar.xz │ │ +-rw-r--r-- 0 0 0 13368 2024-01-05 13:47:47.000000 control.tar.xz │ │ +-rw-r--r-- 0 0 0 3706484 2024-01-05 13:47:47.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 │ │ │ │ @@ -590,15 +590,15 @@ │ │ │ │
│ │ │ │

1.0 Changelog

│ │ │ │
│ │ │ │

1.0.19

│ │ │ │ Released: August 3, 2017
│ │ │ │

oracle

│ │ │ │
    │ │ │ │ -

  • [oracle] [bug] [performance] [py2k]

    Fixed performance regression caused by the fix for #3937 where │ │ │ │ +

  • [oracle] [performance] [bug] [py2k]

    Fixed performance regression caused by the fix for #3937 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 are no longer necessary and are disabled if │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -316,15 +316,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, 2017
│ │ │ │

oracle

│ │ │ │
    │ │ │ │ -

  • [oracle] [bug] [performance] [py2k]

    Fixed performance regression caused by the fix for #3937 where │ │ │ │ +

  • [oracle] [performance] [bug] [py2k]

    Fixed performance regression caused by the fix for #3937 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 are no longer necessary and are disabled if │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -495,15 +495,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 │ │ │ │ @@ -2979,15 +2979,15 @@ │ │ │ │

    │ │ │ │
    • │ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │

oracle

│ │ │ │
    │ │ │ │ -

  • [oracle] [bug] [performance] [py2k]

    Fixed performance regression caused by the fix for #3937 where │ │ │ │ +

  • [oracle] [performance] [bug] [py2k]

    Fixed performance regression caused by the fix for #3937 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 are no longer necessary and are disabled if │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -1878,15 +1878,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

│ │ │ │
    │ │ │ │ -

  • [oracle] [bug]

    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

    │ │ │ │ -

    │ │ │ │ -
    • │ │ │ │ -

  • [oracle] [bug] [performance]

    Changed the implementation of fetching CLOB and BLOB objects to use │ │ │ │ +

  • [oracle] [performance] [bug]

    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

    │ │ │ │

    │ │ │ │
    • │ │ │ │ +

  • [oracle] [bug]

    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

    │ │ │ │ +

    │ │ │ │ +
    • │ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │

firebird

│ │ │ │
    │ │ │ │

  • [firebird] [change]

    Adjusted dialect loading for firebird:// URIs so the external │ │ │ │ sqlalchemy-firebird dialect will be used if it has been installed, │ │ │ │ @@ -2204,15 +2204,15 @@ │ │ │ │

    misc

    │ │ │ │
      │ │ │ │

    • [usecase] [ext]

      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

      │ │ │ │

      │ │ │ │
      • │ │ │ │ -

    • [bug] [performance]

      Revised an internal change to the test system added as a result of │ │ │ │ +

    • [performance] [bug]

      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 │ │ │ │ │ ******** ffiirreebbiirrdd_?¶ ******** │ │ │ │ │ * [[ffiirreebbiirrdd]] [[cchhaannggee]] _¶ │ │ │ │ │ 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 │ │ │ │ @@ -2857,36 +2857,36 @@ │ │ │ │ attributes and entities that are installed as part of an Insert, │ │ │ │ Update, or Delete construct. The │ │ │ │ Select.column_descriptions accessor is also now implemented for │ │ │ │ Core-only selectables.

      │ │ │ │

      References: #7861

      │ │ │ │

      │ │ │ │
      • │ │ │ │ -

    • [orm] [bug] [regression]

      Fixed regression in “dynamic” loader strategy where the │ │ │ │ +

    • [orm] [performance] [bug]

      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

      │ │ │ │ +

      │ │ │ │ +
      • │ │ │ │ +

    • [orm] [bug] [regression]

      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

      │ │ │ │

      │ │ │ │
      • │ │ │ │ -

    • [orm] [bug]

      Fixed bug where composite() attributes would not work in │ │ │ │ +

    • [orm] [bug]

      Fixed bug where composite() attributes would not work in │ │ │ │ conjunction with the selectin_polymorphic() loader strategy for │ │ │ │ joined table inheritance.

      │ │ │ │

      References: #7801

      │ │ │ │

      │ │ │ │
      • │ │ │ │ -

    • [orm] [bug] [performance]

      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

      │ │ │ │ -

      │ │ │ │ -
      • │ │ │ │

    • [orm] [bug]

      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

      │ │ │ │

      │ │ │ │
      • │ │ │ │ @@ -4612,15 +4612,15 @@ │ │ │ │

      │ │ │ │ │ │ │ │
    │ │ │ │
│ │ │ │
│ │ │ │

oracle

│ │ │ │
    │ │ │ │ -

  • [oracle] [bug] [performance]

    Added a CAST(VARCHAR2(128)) to the “table name”, “owner”, and other │ │ │ │ +

  • [oracle] [performance] [bug]

    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 │ │ │ │ @@ -5334,15 +5334,24 @@ │ │ │ │

│ │ │ │
│ │ │ │
│ │ │ │

1.4.18

│ │ │ │ Released: June 10, 2021
│ │ │ │

orm

│ │ │ │
    │ │ │ │ -

  • [orm] [bug]

    Clarified the current purpose of the │ │ │ │ +

  • [orm] [performance] [bug] [regression]

    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

    │ │ │ │ +

    │ │ │ │ +
    • │ │ │ │ +

  • [orm] [bug]

    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 │ │ │ │ @@ -5352,38 +5361,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.

    │ │ │ │

    References: #6072, #6487

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [orm] [bug] [regression]

    Adjusted the means by which classes such as scoped_session │ │ │ │ +

  • [orm] [bug] [regression]

    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

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [orm] [bug] [regression]

    Fixed issue where query production for joinedload against a complex left │ │ │ │ +

  • [orm] [bug] [regression]

    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

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [orm] [bug] [performance] [regression]

    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

    │ │ │ │ -

    │ │ │ │ -
    • │ │ │ │

  • [orm] [bug]

    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

    │ │ │ │

    │ │ │ │
    • │ │ │ │

  • [orm] [bug]

    The warning that’s emitted for relationship() when multiple │ │ │ │ @@ -6227,15 +6227,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

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [orm] [bug] [performance] [regression] [sql]

    Fixed a critical performance issue where the traversal of a │ │ │ │ +

  • [orm] [performance] [bug] [regression] [sql]

    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 referred towards 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 │ │ │ │ @@ -9028,15 +9028,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 │ │ │ │ @@ -9047,21 +9054,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 {} │ │ │ │ │ @@ -1901,31 +1901,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]] _¶ │ │ │ │ │ @@ -3123,15 +3123,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. │ │ │ │ │ @@ -3631,51 +3631,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 │ │ │ │ │ @@ -4245,15 +4244,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 referred towards 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 │ │ │ │ │ @@ -6223,15 +6222,21 @@ │ │ │ │ │ returned by the ResultProxy is now the _L_e_g_a_c_y_R_o_w 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 │ │ │ │ │ @@ -6239,20 +6244,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 _S_t_r_i_n_g_._R_E_T_U_R_N_S___C_O_N_D_I_T_I_O_N_A_L or │ │ │ │ │ _S_t_r_i_n_g_._R_E_T_U_R_N_S___B_Y_T_E_S, 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 │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html │ │ │ │┄ Ordering differences only │ │ │ │ @@ -308,46 +308,46 @@ │ │ │ │

│ │ │ │
│ │ │ │

Associations

│ │ │ │

Examples illustrating the usage of the “association object” pattern, │ │ │ │ where an intermediary class mediates the relationship between two │ │ │ │ classes that are associated in a many-to-many pattern.

│ │ │ │

Listing of files:

    │ │ │ │ +

  • basic_association.py - Illustrate a many-to-many relationship between an │ │ │ │ +“Order” and a collection of “Item” objects, associating a purchase price │ │ │ │ +with each via an association object called “OrderItem”

    │ │ │ │ +

    • │ │ │ │

  • dict_of_sets_with_default.py - An advanced association proxy example which │ │ │ │ illustrates nesting of association proxies to produce multi-level Python │ │ │ │ collections, in this case a dictionary with string keys and sets of integers │ │ │ │ as values, which conceal the underlying mapped classes.

    │ │ │ │

    • │ │ │ │

  • proxied_association.py - Same example as basic_association, adding in │ │ │ │ usage of sqlalchemy.ext.associationproxy to make explicit references │ │ │ │ to OrderItem optional.

    │ │ │ │

    • │ │ │ │ -

  • basic_association.py - Illustrate a many-to-many relationship between an │ │ │ │ -“Order” and a collection of “Item” objects, associating a purchase price │ │ │ │ -with each via an association object called “OrderItem”

    │ │ │ │ -

    • │ │ │ │
│ │ │ │

│ │ │ │
│ │ │ │
│ │ │ │

Asyncio Integration

│ │ │ │

Examples illustrating the asyncio engine feature of SQLAlchemy.

│ │ │ │

Listing of files:

    │ │ │ │ -

  • gather_orm_statements.py - Illustrates how to run many statements concurrently using asyncio.gather() │ │ │ │ -along many asyncio database connections, merging ORM results into a single │ │ │ │ -AsyncSession.

    │ │ │ │ -

    • │ │ │ │

  • async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ │ for asynchronous ORM use.

    │ │ │ │

    • │ │ │ │ -

  • basic.py - Illustrates the asyncio engine / connection interface.

    │ │ │ │ +

  • gather_orm_statements.py - Illustrates how to run many statements concurrently using asyncio.gather() │ │ │ │ +along many asyncio database connections, merging ORM results into a single │ │ │ │ +AsyncSession.

    │ │ │ │

    • │ │ │ │

  • greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ │ for asynchronous ORM use, including the optional run_sync() method.

    │ │ │ │

    • │ │ │ │ +

  • basic.py - Illustrates the asyncio engine / connection interface.

    │ │ │ │ +

    • │ │ │ │
│ │ │ │

│ │ │ │
│ │ │ │
│ │ │ │

Directed Graphs

│ │ │ │

An example of persistence for a directed graph structure. The │ │ │ │ graph is stored as a collection of edges, each referencing both a │ │ │ │ @@ -388,32 +388,32 @@ │ │ │ │ are modernized versions of recipes presented in the 2007 blog post │ │ │ │ Polymorphic Associations with SQLAlchemy.

│ │ │ │

Listing of files:

    │ │ │ │

  • table_per_related.py - Illustrates a generic association which persists association │ │ │ │ objects within individual tables, each one generated to persist │ │ │ │ those objects on behalf of a particular parent class.

    │ │ │ │

    • │ │ │ │ -

  • generic_fk.py - Illustrates a so-called “generic foreign key”, in a similar fashion │ │ │ │ -to that of popular frameworks such as Django, ROR, etc. This │ │ │ │ -approach bypasses standard referential integrity │ │ │ │ -practices, in that the “foreign key” column is not actually │ │ │ │ -constrained to refer to any particular table; instead, │ │ │ │ -in-application logic is used to determine which table is referenced.

    │ │ │ │ +

  • table_per_association.py - Illustrates a mixin which provides a generic association │ │ │ │ +via a individually generated association tables for each parent class. │ │ │ │ +The associated objects themselves are persisted in a single table │ │ │ │ +shared among all parents.

    │ │ │ │

    • │ │ │ │

  • discriminator_on_association.py - Illustrates a mixin which provides a generic association │ │ │ │ using a single target table and a single association table, │ │ │ │ referred to by all parent tables. The association table │ │ │ │ contains a “discriminator” column which determines what type of │ │ │ │ parent object associates to each particular row in the association │ │ │ │ table.

    │ │ │ │

    • │ │ │ │ -

  • table_per_association.py - Illustrates a mixin which provides a generic association │ │ │ │ -via a individually generated association tables for each parent class. │ │ │ │ -The associated objects themselves are persisted in a single table │ │ │ │ -shared among all parents.

    │ │ │ │ +

  • generic_fk.py - Illustrates a so-called “generic foreign key”, in a similar fashion │ │ │ │ +to that of popular frameworks such as Django, ROR, etc. This │ │ │ │ +approach bypasses standard referential integrity │ │ │ │ +practices, in that the “foreign key” column is not actually │ │ │ │ +constrained to refer to any particular table; instead, │ │ │ │ +in-application logic is used to determine which table is referenced.

    │ │ │ │

    • │ │ │ │
│ │ │ │

│ │ │ │
│ │ │ │
│ │ │ │

Large Collections

│ │ │ │

Large collection example.

│ │ │ │ @@ -503,30 +503,30 @@ │ │ │ │ │ │ │ │
│ │ │ │

File Listing

│ │ │ │

Listing of files:

    │ │ │ │

  • bulk_updates.py - This series of tests will illustrate different ways to UPDATE a large number │ │ │ │ of rows in bulk (under construction! there’s just one test at the moment)

    │ │ │ │

    • │ │ │ │ +

  • large_resultsets.py - In this series of tests, we are looking at time to load a large number │ │ │ │ +of very small and simple rows.

    │ │ │ │ +

    • │ │ │ │

  • single_inserts.py - In this series of tests, we’re looking at a method that inserts a row │ │ │ │ within a distinct transaction, and afterwards returns to essentially a │ │ │ │ “closed” state. This would be analogous to an API call that starts up │ │ │ │ a database connection, inserts the row, commits and closes.

    │ │ │ │

    • │ │ │ │ -

  • bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number │ │ │ │ -of rows in bulk.

    │ │ │ │ -

    • │ │ │ │ -

  • large_resultsets.py - In this series of tests, we are looking at time to load a large number │ │ │ │ -of very small and simple rows.

    │ │ │ │ -

    • │ │ │ │

  • __main__.py - Allows the examples/performance package to be run as a script.

    │ │ │ │

    • │ │ │ │

  • short_selects.py - This series of tests illustrates different ways to SELECT a single │ │ │ │ record by primary key

    │ │ │ │

    • │ │ │ │ +

  • bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number │ │ │ │ +of rows in bulk.

    │ │ │ │ +

    • │ │ │ │
│ │ │ │

│ │ │ │
│ │ │ │
│ │ │ │

Running all tests with time

│ │ │ │

This is the default form of run:

│ │ │ │ 
$ python -m examples.performance single_inserts
│ │ │ │ @@ -668,22 +668,22 @@
│ │ │ │
│ │ │ │
│ │ │ │

Relationship Join Conditions

│ │ │ │

Examples of various relationship() configurations, │ │ │ │ which make use of the primaryjoin argument to compose special types │ │ │ │ of join conditions.

│ │ │ │

Listing of files:

    │ │ │ │ -

  • threeway.py - Illustrate a “three way join” - where a primary table joins to a remote │ │ │ │ -table via an association table, but then the primary table also needs │ │ │ │ -to refer to some columns in the remote table directly.

    │ │ │ │ -

    • │ │ │ │

  • cast.py - Illustrate a relationship() that joins two columns where those │ │ │ │ columns are not of the same type, and a CAST must be used on the SQL │ │ │ │ side in order to match them.

    │ │ │ │

    • │ │ │ │ +

  • threeway.py - Illustrate a “three way join” - where a primary table joins to a remote │ │ │ │ +table via an association table, but then the primary table also needs │ │ │ │ +to refer to some columns in the remote table directly.

    │ │ │ │ +

    • │ │ │ │
│ │ │ │

│ │ │ │
│ │ │ │
│ │ │ │

Space Invaders

│ │ │ │

A Space Invaders game using SQLite as the state machine.

│ │ │ │

Originally developed in 2012. Adapted to work in Python 3.

│ │ │ │ @@ -838,23 +838,23 @@ │ │ │ │ concept of a “vertical table” structure, like those illustrated in │ │ │ │ Vertical Attribute Mapping examples.

│ │ │ │

│ │ │ │

  • versioned_rows.py - Illustrates a method to intercept changes on objects, turning │ │ │ │ an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ │ row is inserted with the new data, keeping the old row intact.

    │ │ │ │

    • │ │ │ │ -

  • versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning │ │ │ │ -an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ │ -row is inserted with the new data, keeping the old row intact.

    │ │ │ │ -

    • │ │ │ │

  • versioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique of versioned_rows.py, │ │ │ │ but also emits an UPDATE on the old row to affect a change in timestamp. │ │ │ │ Also includes a SessionEvents.do_orm_execute() hook to limit queries │ │ │ │ to only the most recent version.

    │ │ │ │

    • │ │ │ │ +

  • versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning │ │ │ │ +an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ │ +row is inserted with the new data, keeping the old row intact.

    │ │ │ │ +

    • │ │ │ │ │ │ │ │

    │ │ │ │
    │ │ │ │
    │ │ │ │
    │ │ │ │

    Vertical Attribute Mapping

    │ │ │ │

    Illustrates “vertical table” mappings.

    │ │ │ │ @@ -879,57 +879,57 @@ │ │ │ │ q = (session.query(Animal). │ │ │ │ filter(Animal.facts.any( │ │ │ │ and_(AnimalFact.key == u'weasel-like', │ │ │ │ AnimalFact.value == True)))) │ │ │ │ print('weasel-like animals', q.all()) │ │ │ │ │ │ │ │

    Listing of files:

      │ │ │ │ -

    • dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.

      │ │ │ │ -

      • │ │ │ │

    • dictlike.py - Mapping a vertical table as a dictionary.

      │ │ │ │

      • │ │ │ │ +

    • dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.

      │ │ │ │ +

      • │ │ │ │
    │ │ │ │

    │ │ │ │
    │ │ │ │
    │ │ │ │
    │ │ │ │

    Inheritance Mapping Recipes

    │ │ │ │
    │ │ │ │

    Basic Inheritance Mappings

    │ │ │ │

    Working examples of single-table, joined-table, and concrete-table │ │ │ │ inheritance as described in Mapping Class Inheritance Hierarchies.

    │ │ │ │

    Listing of files:

      │ │ │ │ -

    • single.py - Single-table (table-per-hierarchy) inheritance example.

      │ │ │ │ -

      • │ │ │ │

    • concrete.py - Concrete-table (table-per-class) inheritance example.

      │ │ │ │

      • │ │ │ │

    • joined.py - Joined-table (table-per-subclass) inheritance example.

      │ │ │ │

      • │ │ │ │ +

    • single.py - Single-table (table-per-hierarchy) inheritance example.

      │ │ │ │ +

      • │ │ │ │
    │ │ │ │

    │ │ │ │
    │ │ │ │
    │ │ │ │
    │ │ │ │

    Special APIs

    │ │ │ │
    │ │ │ │

    Attribute Instrumentation

    │ │ │ │

    Examples illustrating modifications to SQLAlchemy’s attribute management │ │ │ │ system.

    │ │ │ │

    Listing of files:

    │ │ │ │

    │ │ │ │
    │ │ │ │
    │ │ │ │

    Horizontal Sharding

    │ │ │ │

    A basic example of using the SQLAlchemy Sharding API. │ │ │ │ Sharding refers to horizontally scaling data across multiple │ │ │ │ @@ -958,21 +958,21 @@ │ │ │ │

    The construction of generic sharding routines is an ambitious approach │ │ │ │ to the issue of organizing instances among multiple databases. For a │ │ │ │ more plain-spoken alternative, the “distinct entity” approach │ │ │ │ is a simple method of assigning objects to different tables (and potentially │ │ │ │ database nodes) in an explicit way - described on the wiki at │ │ │ │ EntityName.

    │ │ │ │

    Listing of files:

      │ │ │ │ -

    • separate_tables.py - Illustrates sharding using a single SQLite database, that will however │ │ │ │ -have multiple tables using a naming convention.

      │ │ │ │ +

    • separate_databases.py - Illustrates sharding using distinct SQLite databases.

      │ │ │ │

      • │ │ │ │

    • separate_schema_translates.py - Illustrates sharding using a single database with multiple schemas, │ │ │ │ where a different “schema_translates_map” can be used for each shard.

      │ │ │ │

      • │ │ │ │ -

    • separate_databases.py - Illustrates sharding using distinct SQLite databases.

      │ │ │ │ +

    • separate_tables.py - Illustrates sharding using a single SQLite database, that will however │ │ │ │ +have multiple tables using a naming convention.

      │ │ │ │

      • │ │ │ │
    │ │ │ │

    │ │ │ │
    │ │ │ │
    │ │ │ │
    │ │ │ │

    Extending the ORM

    │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -105,35 +105,35 @@ │ │ │ │ │ Listing of files: │ │ │ │ │ * _a_d_j_a_c_e_n_c_y___l_i_s_t_._p_y │ │ │ │ │ ******** AAssssoocciiaattiioonnss_?¶ ******** │ │ │ │ │ Examples illustrating the usage of the “association object” pattern, where an │ │ │ │ │ intermediary class mediates the relationship between two classes that are │ │ │ │ │ associated in a many-to-many pattern. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _d_i_c_t___o_f___s_e_t_s___w_i_t_h___d_e_f_a_u_l_t_._p_y - An advanced association proxy example │ │ │ │ │ - which illustrates nesting of association proxies to produce multi-level │ │ │ │ │ - Python collections, in this case a dictionary with string keys and sets │ │ │ │ │ - of integers as values, which conceal the underlying mapped classes. │ │ │ │ │ + * _b_a_s_i_c___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrate a many-to-many relationship between an │ │ │ │ │ + “Order” and a collection of “Item” objects, associating a purchase price │ │ │ │ │ + with each via an association object called “OrderItem” │ │ │ │ │ +_d_i_c_t___o_f___s_e_t_s___w_i_t_h___d_e_f_a_u_l_t_._p_y - An advanced association proxy example which │ │ │ │ │ +illustrates nesting of association proxies to produce multi-level Python │ │ │ │ │ +collections, in this case a dictionary with string keys and sets of integers as │ │ │ │ │ +values, which conceal the underlying mapped classes. │ │ │ │ │ _p_r_o_x_i_e_d___a_s_s_o_c_i_a_t_i_o_n_._p_y - Same example as basic_association, adding in usage of │ │ │ │ │ _s_q_l_a_l_c_h_e_m_y_._e_x_t_._a_s_s_o_c_i_a_t_i_o_n_p_r_o_x_y to make explicit references to OrderItem │ │ │ │ │ optional. │ │ │ │ │ -_b_a_s_i_c___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrate a many-to-many relationship between an │ │ │ │ │ -“Order” and a collection of “Item” objects, associating a purchase price with │ │ │ │ │ -each via an association object called “OrderItem” │ │ │ │ │ ******** AAssyynncciioo IInntteeggrraattiioonn_?¶ ******** │ │ │ │ │ Examples illustrating the asyncio engine feature of SQLAlchemy. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _g_a_t_h_e_r___o_r_m___s_t_a_t_e_m_e_n_t_s_._p_y - Illustrates how to run many statements │ │ │ │ │ - concurrently using asyncio.gather() along many asyncio database │ │ │ │ │ - connections, merging ORM results into a single AsyncSession. │ │ │ │ │ -_a_s_y_n_c___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ -object for asynchronous ORM use. │ │ │ │ │ -_b_a_s_i_c_._p_y - Illustrates the asyncio engine / connection interface. │ │ │ │ │ + * _a_s_y_n_c___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ + object for asynchronous ORM use. │ │ │ │ │ +_g_a_t_h_e_r___o_r_m___s_t_a_t_e_m_e_n_t_s_._p_y - Illustrates how to run many statements concurrently │ │ │ │ │ +using asyncio.gather() along many asyncio database connections, merging ORM │ │ │ │ │ +results into a single AsyncSession. │ │ │ │ │ _g_r_e_e_n_l_e_t___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ object for asynchronous ORM use, including the optional run_sync() method. │ │ │ │ │ +_b_a_s_i_c_._p_y - Illustrates the asyncio engine / connection interface. │ │ │ │ │ ******** DDiirreecctteedd GGrraapphhss_?¶ ******** │ │ │ │ │ An example of persistence for a directed graph structure. The graph is stored │ │ │ │ │ as a collection of edges, each referencing both a “lower” and an “upper” node │ │ │ │ │ in a table of nodes. Basic persistence and querying for lower- and upper- │ │ │ │ │ neighbors are illustrated: │ │ │ │ │ n2 = Node(2) │ │ │ │ │ n5 = Node(5) │ │ │ │ │ @@ -158,28 +158,28 @@ │ │ │ │ │ The _d_i_s_c_r_i_m_i_n_a_t_o_r___o_n___a_s_s_o_c_i_a_t_i_o_n_._p_y and _g_e_n_e_r_i_c___f_k_._p_y scripts are modernized │ │ │ │ │ versions of recipes presented in the 2007 blog post _P_o_l_y_m_o_r_p_h_i_c_ _A_s_s_o_c_i_a_t_i_o_n_s │ │ │ │ │ _w_i_t_h_ _S_Q_L_A_l_c_h_e_m_y. │ │ │ │ │ Listing of files: │ │ │ │ │ * _t_a_b_l_e___p_e_r___r_e_l_a_t_e_d_._p_y - Illustrates a generic association which persists │ │ │ │ │ association objects within individual tables, each one generated to │ │ │ │ │ persist those objects on behalf of a particular parent class. │ │ │ │ │ -_g_e_n_e_r_i_c___f_k_._p_y - Illustrates a so-called “generic foreign key”, in a similar │ │ │ │ │ -fashion to that of popular frameworks such as Django, ROR, etc. This approach │ │ │ │ │ -bypasses standard referential integrity practices, in that the “foreign key” │ │ │ │ │ -column is not actually constrained to refer to any particular table; instead, │ │ │ │ │ -in-application logic is used to determine which table is referenced. │ │ │ │ │ +_t_a_b_l_e___p_e_r___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic │ │ │ │ │ +association via a individually generated association tables for each parent │ │ │ │ │ +class. The associated objects themselves are persisted in a single table shared │ │ │ │ │ +among all parents. │ │ │ │ │ _d_i_s_c_r_i_m_i_n_a_t_o_r___o_n___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic │ │ │ │ │ association using a single target table and a single association table, │ │ │ │ │ referred to by all parent tables. The association table contains a │ │ │ │ │ “discriminator” column which determines what type of parent object associates │ │ │ │ │ to each particular row in the association table. │ │ │ │ │ -_t_a_b_l_e___p_e_r___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic │ │ │ │ │ -association via a individually generated association tables for each parent │ │ │ │ │ -class. The associated objects themselves are persisted in a single table shared │ │ │ │ │ -among all parents. │ │ │ │ │ +_g_e_n_e_r_i_c___f_k_._p_y - Illustrates a so-called “generic foreign key”, in a similar │ │ │ │ │ +fashion to that of popular frameworks such as Django, ROR, etc. This approach │ │ │ │ │ +bypasses standard referential integrity practices, in that the “foreign key” │ │ │ │ │ +column is not actually constrained to refer to any particular table; instead, │ │ │ │ │ +in-application logic is used to determine which table is referenced. │ │ │ │ │ ******** LLaarrggee CCoolllleeccttiioonnss_?¶ ******** │ │ │ │ │ Large collection example. │ │ │ │ │ Illustrates the options to use with _r_e_l_a_t_i_o_n_s_h_i_p_(_) when the list of related │ │ │ │ │ objects is very large, including: │ │ │ │ │ * “dynamic” relationships which query slices of data as accessed │ │ │ │ │ * how to use ON DELETE CASCADE in conjunction with passive_deletes=True to │ │ │ │ │ greatly improve the performance of related collection deletion. │ │ │ │ │ @@ -239,25 +239,25 @@ │ │ │ │ │ See also │ │ │ │ │ _H_o_w_ _c_a_n_ _I_ _p_r_o_f_i_l_e_ _a_ _S_Q_L_A_l_c_h_e_m_y_ _p_o_w_e_r_e_d_ _a_p_p_l_i_c_a_t_i_o_n_? │ │ │ │ │ ****** FFiillee LLiissttiinngg_?¶ ****** │ │ │ │ │ Listing of files: │ │ │ │ │ * _b_u_l_k___u_p_d_a_t_e_s_._p_y - This series of tests will illustrate different ways to │ │ │ │ │ UPDATE a large number of rows in bulk (under construction! there’s just │ │ │ │ │ one test at the moment) │ │ │ │ │ +_l_a_r_g_e___r_e_s_u_l_t_s_e_t_s_._p_y - In this series of tests, we are looking at time to load a │ │ │ │ │ +large number of very small and simple rows. │ │ │ │ │ _s_i_n_g_l_e___i_n_s_e_r_t_s_._p_y - In this series of tests, we’re looking at a method that │ │ │ │ │ inserts a row within a distinct transaction, and afterwards returns to │ │ │ │ │ essentially a “closed” state. This would be analogous to an API call that │ │ │ │ │ starts up a database connection, inserts the row, commits and closes. │ │ │ │ │ -_b_u_l_k___i_n_s_e_r_t_s_._p_y - This series of tests illustrates different ways to INSERT a │ │ │ │ │ -large number of rows in bulk. │ │ │ │ │ -_l_a_r_g_e___r_e_s_u_l_t_s_e_t_s_._p_y - In this series of tests, we are looking at time to load a │ │ │ │ │ -large number of very small and simple rows. │ │ │ │ │ _____m_a_i_n_____._p_y - Allows the examples/performance package to be run as a script. │ │ │ │ │ _s_h_o_r_t___s_e_l_e_c_t_s_._p_y - This series of tests illustrates different ways to SELECT a │ │ │ │ │ single record by primary key │ │ │ │ │ +_b_u_l_k___i_n_s_e_r_t_s_._p_y - This series of tests illustrates different ways to INSERT a │ │ │ │ │ +large number of rows in bulk. │ │ │ │ │ ****** RRuunnnniinngg aallll tteessttss wwiitthh ttiimmee_?¶ ****** │ │ │ │ │ This is the default form of run: │ │ │ │ │ $ python -m examples.performance single_inserts │ │ │ │ │ Tests to run: test_orm_commit, test_bulk_save, │ │ │ │ │ test_bulk_insert_dictionaries, test_core, │ │ │ │ │ test_core_query_caching, test_dbapi_raw_w_connect, │ │ │ │ │ test_dbapi_raw_w_pool │ │ │ │ │ @@ -394,20 +394,20 @@ │ │ │ │ │ total time 2.754592 sec │ │ │ │ │ test_subqueryload : load everything, subquery eager loading. (1000 iterations); │ │ │ │ │ total time 2.977696 sec │ │ │ │ │ ******** RReellaattiioonnsshhiipp JJooiinn CCoonnddiittiioonnss_?¶ ******** │ │ │ │ │ Examples of various _r_e_l_a_t_i_o_n_s_h_i_p_(_) configurations, which make use of the │ │ │ │ │ primaryjoin argument to compose special types of join conditions. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _t_h_r_e_e_w_a_y_._p_y - Illustrate a “three way join” - where a primary table joins │ │ │ │ │ - to a remote table via an association table, but then the primary table │ │ │ │ │ - also needs to refer to some columns in the remote table directly. │ │ │ │ │ -_c_a_s_t_._p_y - Illustrate a _r_e_l_a_t_i_o_n_s_h_i_p_(_) that joins two columns where those │ │ │ │ │ -columns are not of the same type, and a CAST must be used on the SQL side in │ │ │ │ │ -order to match them. │ │ │ │ │ + * _c_a_s_t_._p_y - Illustrate a _r_e_l_a_t_i_o_n_s_h_i_p_(_) that joins two columns where those │ │ │ │ │ + columns are not of the same type, and a CAST must be used on the SQL side │ │ │ │ │ + in order to match them. │ │ │ │ │ +_t_h_r_e_e_w_a_y_._p_y - Illustrate a “three way join” - where a primary table joins to a │ │ │ │ │ +remote table via an association table, but then the primary table also needs to │ │ │ │ │ +refer to some columns in the remote table directly. │ │ │ │ │ ******** SSppaaccee IInnvvaaddeerrss_?¶ ******** │ │ │ │ │ A Space Invaders game using SQLite as the state machine. │ │ │ │ │ Originally developed in 2012. Adapted to work in Python 3. │ │ │ │ │ Runs in a textual console using ASCII art. │ │ │ │ │ [../_images/space_invaders.jpg] │ │ │ │ │ To run: │ │ │ │ │ python -m examples.space_invaders.space_invaders │ │ │ │ │ @@ -527,21 +527,21 @@ │ │ │ │ │ Listing of files: │ │ │ │ │ * _v_e_r_s_i_o_n_e_d___m_a_p_._p_y - A variant of the versioned_rows example built around │ │ │ │ │ the concept of a “vertical table” structure, like those illustrated in │ │ │ │ │ _V_e_r_t_i_c_a_l_ _A_t_t_r_i_b_u_t_e_ _M_a_p_p_i_n_g examples. │ │ │ │ │ _v_e_r_s_i_o_n_e_d___r_o_w_s_._p_y - Illustrates a method to intercept changes on objects, │ │ │ │ │ turning an UPDATE statement on a single row into an INSERT statement, so that a │ │ │ │ │ new row is inserted with the new data, keeping the old row intact. │ │ │ │ │ -_v_e_r_s_i_o_n_e_d___r_o_w_s___w___v_e_r_s_i_o_n_i_d_._p_y - Illustrates a method to intercept changes on │ │ │ │ │ -objects, turning an UPDATE statement on a single row into an INSERT statement, │ │ │ │ │ -so that a new row is inserted with the new data, keeping the old row intact. │ │ │ │ │ _v_e_r_s_i_o_n_e_d___u_p_d_a_t_e___o_l_d___r_o_w_._p_y - Illustrates the same UPDATE into INSERT technique │ │ │ │ │ of versioned_rows.py, but also emits an UPDATE on the oolldd row to affect a │ │ │ │ │ change in timestamp. Also includes a _S_e_s_s_i_o_n_E_v_e_n_t_s_._d_o___o_r_m___e_x_e_c_u_t_e_(_) hook to │ │ │ │ │ limit queries to only the most recent version. │ │ │ │ │ +_v_e_r_s_i_o_n_e_d___r_o_w_s___w___v_e_r_s_i_o_n_i_d_._p_y - Illustrates a method to intercept changes on │ │ │ │ │ +objects, turning an UPDATE statement on a single row into an INSERT statement, │ │ │ │ │ +so that a new row is inserted with the new data, keeping the old row intact. │ │ │ │ │ ******** VVeerrttiiccaall AAttttrriibbuuttee MMaappppiinngg_?¶ ******** │ │ │ │ │ Illustrates “vertical table” mappings. │ │ │ │ │ A “vertical table” refers to a technique where individual attributes of an │ │ │ │ │ object are stored as distinct rows in a table. The “vertical table” technique │ │ │ │ │ is used to persist objects which can have a varied set of attributes, at the │ │ │ │ │ expense of simple query control and brevity. It is commonly found in content/ │ │ │ │ │ document management systems in order to represent user-created structures │ │ │ │ │ @@ -560,38 +560,37 @@ │ │ │ │ │ │ │ │ │ │ q = (session.query(Animal). │ │ │ │ │ filter(Animal.facts.any( │ │ │ │ │ and_(AnimalFact.key == u'weasel-like', │ │ │ │ │ AnimalFact.value == True)))) │ │ │ │ │ print('weasel-like animals', q.all()) │ │ │ │ │ Listing of files: │ │ │ │ │ - * _d_i_c_t_l_i_k_e_-_p_o_l_y_m_o_r_p_h_i_c_._p_y - Mapping a polymorphic-valued vertical table as │ │ │ │ │ - a dictionary. │ │ │ │ │ -_d_i_c_t_l_i_k_e_._p_y - Mapping a vertical table as a dictionary. │ │ │ │ │ + * _d_i_c_t_l_i_k_e_._p_y - Mapping a vertical table as a dictionary. │ │ │ │ │ +_d_i_c_t_l_i_k_e_-_p_o_l_y_m_o_r_p_h_i_c_._p_y - Mapping a polymorphic-valued vertical table as a │ │ │ │ │ +dictionary. │ │ │ │ │ ********** IInnhheerriittaannccee MMaappppiinngg RReecciippeess_?¶ ********** │ │ │ │ │ ******** BBaassiicc IInnhheerriittaannccee MMaappppiinnggss_?¶ ******** │ │ │ │ │ Working examples of single-table, joined-table, and concrete-table inheritance │ │ │ │ │ as described in _M_a_p_p_i_n_g_ _C_l_a_s_s_ _I_n_h_e_r_i_t_a_n_c_e_ _H_i_e_r_a_r_c_h_i_e_s. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _s_i_n_g_l_e_._p_y - Single-table (table-per-hierarchy) inheritance example. │ │ │ │ │ -_c_o_n_c_r_e_t_e_._p_y - Concrete-table (table-per-class) inheritance example. │ │ │ │ │ + * _c_o_n_c_r_e_t_e_._p_y - Concrete-table (table-per-class) inheritance example. │ │ │ │ │ _j_o_i_n_e_d_._p_y - Joined-table (table-per-subclass) inheritance example. │ │ │ │ │ +_s_i_n_g_l_e_._p_y - Single-table (table-per-hierarchy) inheritance example. │ │ │ │ │ ********** SSppeecciiaall AAPPIIss_?¶ ********** │ │ │ │ │ ******** AAttttrriibbuuttee IInnssttrruummeennttaattiioonn_?¶ ******** │ │ │ │ │ Examples illustrating modifications to SQLAlchemy’s attribute management │ │ │ │ │ system. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _a_c_t_i_v_e___c_o_l_u_m_n___d_e_f_a_u_l_t_s_._p_y - Illustrates use of the │ │ │ │ │ - _A_t_t_r_i_b_u_t_e_E_v_e_n_t_s_._i_n_i_t___s_c_a_l_a_r_(_) event, in conjunction with Core column │ │ │ │ │ - defaults to provide ORM objects that automatically produce the default │ │ │ │ │ - value when an un-set attribute is accessed. │ │ │ │ │ + * _c_u_s_t_o_m___m_a_n_a_g_e_m_e_n_t_._p_y - Illustrates customized class instrumentation, │ │ │ │ │ + using the _s_q_l_a_l_c_h_e_m_y_._e_x_t_._i_n_s_t_r_u_m_e_n_t_a_t_i_o_n extension package. │ │ │ │ │ +_a_c_t_i_v_e___c_o_l_u_m_n___d_e_f_a_u_l_t_s_._p_y - Illustrates use of the _A_t_t_r_i_b_u_t_e_E_v_e_n_t_s_._i_n_i_t___s_c_a_l_a_r │ │ │ │ │ +_(_) event, in conjunction with Core column defaults to provide ORM objects that │ │ │ │ │ +automatically produce the default value when an un-set attribute is accessed. │ │ │ │ │ _l_i_s_t_e_n___f_o_r___e_v_e_n_t_s_._p_y - Illustrates how to attach events to all instrumented │ │ │ │ │ attributes and listen for change events. │ │ │ │ │ -_c_u_s_t_o_m___m_a_n_a_g_e_m_e_n_t_._p_y - Illustrates customized class instrumentation, using the │ │ │ │ │ -_s_q_l_a_l_c_h_e_m_y_._e_x_t_._i_n_s_t_r_u_m_e_n_t_a_t_i_o_n extension package. │ │ │ │ │ ******** HHoorriizzoonnttaall SShhaarrddiinngg_?¶ ******** │ │ │ │ │ A basic example of using the SQLAlchemy Sharding API. Sharding refers to │ │ │ │ │ horizontally scaling data across multiple databases. │ │ │ │ │ The basic components of a “sharded” mapping are: │ │ │ │ │ * multiple _E_n_g_i_n_e instances, each assigned a “shard id”. These _E_n_g_i_n_e │ │ │ │ │ instances may refer to different databases, or different schemas / │ │ │ │ │ accounts within the same database, or they can even be differentiated │ │ │ │ │ @@ -612,20 +611,21 @@ │ │ │ │ │ attempt to determine a single shard being requested. │ │ │ │ │ The construction of generic sharding routines is an ambitious approach to the │ │ │ │ │ issue of organizing instances among multiple databases. For a more plain-spoken │ │ │ │ │ alternative, the “distinct entity” approach is a simple method of assigning │ │ │ │ │ objects to different tables (and potentially database nodes) in an explicit way │ │ │ │ │ - described on the wiki at _E_n_t_i_t_y_N_a_m_e. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _s_e_p_a_r_a_t_e___t_a_b_l_e_s_._p_y - Illustrates sharding using a single SQLite database, │ │ │ │ │ - that will however have multiple tables using a naming convention. │ │ │ │ │ + * _s_e_p_a_r_a_t_e___d_a_t_a_b_a_s_e_s_._p_y - Illustrates sharding using distinct SQLite │ │ │ │ │ + databases. │ │ │ │ │ _s_e_p_a_r_a_t_e___s_c_h_e_m_a___t_r_a_n_s_l_a_t_e_s_._p_y - Illustrates sharding using a single database │ │ │ │ │ with multiple schemas, where a different “schema_translates_map” can be used │ │ │ │ │ for each shard. │ │ │ │ │ -_s_e_p_a_r_a_t_e___d_a_t_a_b_a_s_e_s_._p_y - Illustrates sharding using distinct SQLite databases. │ │ │ │ │ +_s_e_p_a_r_a_t_e___t_a_b_l_e_s_._p_y - Illustrates sharding using a single SQLite database, that │ │ │ │ │ +will however have multiple tables using a naming convention. │ │ │ │ │ ********** EExxtteennddiinngg tthhee OORRMM_?¶ ********** │ │ │ │ │ ******** OORRMM QQuueerryy EEvveennttss_?¶ ******** │ │ │ │ │ Recipes which illustrate augmentation of ORM SELECT behavior as used by │ │ │ │ │ _S_e_s_s_i_o_n_._e_x_e_c_u_t_e_(_) with _2_._0_ _s_t_y_l_e use of _s_e_l_e_c_t_(_), as well as the _1_._x_ _s_t_y_l_e │ │ │ │ │ _Q_u_e_r_y object. │ │ │ │ │ Examples include demonstrations of the _w_i_t_h___l_o_a_d_e_r___c_r_i_t_e_r_i_a_(_) option as well as │ │ │ │ │ the _S_e_s_s_i_o_n_E_v_e_n_t_s_._d_o___o_r_m___e_x_e_c_u_t_e_(_) hook. │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/searchindex.js │ │ │ │ ├── js-beautify {} │ │ │ │ │ @@ -7086,17 +7086,17 @@ │ │ │ │ │ "4138": 12, │ │ │ │ │ "5265": 12, │ │ │ │ │ "5266": 12, │ │ │ │ │ "td": [12, 63], │ │ │ │ │ "protocol": [12, 17, 48, 51, 55, 59, 65, 66, 80, 102, 113], │ │ │ │ │ "5255": 12, │ │ │ │ │ "5271": 12, │ │ │ │ │ + "5314": 12, │ │ │ │ │ "outputtyp": 12, │ │ │ │ │ "5246": 12, │ │ │ │ │ - "5314": 12, │ │ │ │ │ "5278": 12, │ │ │ │ │ "planner": [12, 23, 67], │ │ │ │ │ "5162": 12, │ │ │ │ │ "slot": [12, 56, 87, 91], │ │ │ │ │ "5228": 12, │ │ │ │ │ "5210": 12, │ │ │ │ │ "eval": [12, 75, 84, 124, 140], │ │ │ │ │ @@ -8097,23 +8097,23 @@ │ │ │ │ │ "6583": 13, │ │ │ │ │ "6652": 13, │ │ │ │ │ "majordalla": 13, │ │ │ │ │ "6649": 13, │ │ │ │ │ "6621": 13, │ │ │ │ │ "6132": 13, │ │ │ │ │ "6658": 13, │ │ │ │ │ + "6596": 13, │ │ │ │ │ "bake_queri": [13, 23, 123, 140], │ │ │ │ │ "foundat": [13, 25, 27, 42, 46, 160, 161], │ │ │ │ │ "analysi": [13, 76, 95], │ │ │ │ │ "win": 13, │ │ │ │ │ "6072": 13, │ │ │ │ │ "6487": 13, │ │ │ │ │ "flask": [13, 90], │ │ │ │ │ "6285": 13, │ │ │ │ │ - "6596": 13, │ │ │ │ │ "6591": 13, │ │ │ │ │ "6400": 13, │ │ │ │ │ "async_object_sess": [13, 102], │ │ │ │ │ "async_sess": [13, 102, 123], │ │ │ │ │ "in_nested_transact": [13, 31, 102, 146], │ │ │ │ │ "get_transact": [13, 31, 71, 102, 146, 147], │ │ │ │ │ "get_nested_transact": [13, 31, 102, 146], │ │ │ │ │ @@ -8521,20 +8521,20 @@ │ │ │ │ │ "3414": [13, 25], │ │ │ │ │ "alchemy2": 13, │ │ │ │ │ "4644": 13, │ │ │ │ │ "5649": 13, │ │ │ │ │ "get_sequence_nam": [13, 48, 52], │ │ │ │ │ "2056": 13, │ │ │ │ │ "4755": 13, │ │ │ │ │ + "4524": 13, │ │ │ │ │ "upfront": 13, │ │ │ │ │ "returns_unicode_str": [13, 48], │ │ │ │ │ "returns_condit": [13, 59], │ │ │ │ │ "returns_byt": [13, 59], │ │ │ │ │ "5315": 13, │ │ │ │ │ - "4524": 13, │ │ │ │ │ "hundr": [13, 21, 24, 25, 31, 76, 136, 137, 155], │ │ │ │ │ "4645": [13, 25], │ │ │ │ │ "4808": [13, 25], │ │ │ │ │ "5004": [13, 25], │ │ │ │ │ "har": [13, 25], │ │ │ │ │ "4712": 13, │ │ │ │ │ "5526": [13, 25], │ │ │ │ │ @@ -12459,29 +12459,29 @@ │ │ │ │ │ "receive_class_uninstru": 97, │ │ │ │ │ "rootnod": 98, │ │ │ │ │ "node1": 98, │ │ │ │ │ "node3": 98, │ │ │ │ │ "dump_tre": 98, │ │ │ │ │ "adjacency_list": 98, │ │ │ │ │ "basic_associ": 98, │ │ │ │ │ - "orderitem": 98, │ │ │ │ │ "purchas": 98, │ │ │ │ │ - "gather_orm_stat": 98, │ │ │ │ │ + "orderitem": 98, │ │ │ │ │ "async_orm": 98, │ │ │ │ │ + "gather_orm_stat": 98, │ │ │ │ │ "neighbor": 98, │ │ │ │ │ "n5": 98, │ │ │ │ │ "add_neighbor": 98, │ │ │ │ │ "higher_neighbor": 98, │ │ │ │ │ "directed_graph": 98, │ │ │ │ │ "supplier": 98, │ │ │ │ │ "hasaddress": 98, │ │ │ │ │ "generic_fk": 98, │ │ │ │ │ "table_per_rel": 98, │ │ │ │ │ - "ror": 98, │ │ │ │ │ "table_per_associ": 98, │ │ │ │ │ + "ror": 98, │ │ │ │ │ "materialized_path": 98, │ │ │ │ │ "nested_set": 98, │ │ │ │ │ "single_insert": 98, │ │ │ │ │ "bulk_upd": 98, │ │ │ │ │ "test_orm_commit": 98, │ │ │ │ │ "test_bulk_insert_dictionari": 98, │ │ │ │ │ "test_cor": 98, │ │ │ │ │ @@ -12537,31 +12537,31 @@ │ │ │ │ │ "sc1modifi": 98, │ │ │ │ │ "someclasshistori": 98, │ │ │ │ │ "__history_mapper__": 98, │ │ │ │ │ "_history_mapp": 98, │ │ │ │ │ "somehistoryclass": 98, │ │ │ │ │ "use_mapper_vers": 98, │ │ │ │ │ "versioned_map": 98, │ │ │ │ │ - "versioned_rows_w_versionid": 98, │ │ │ │ │ "versioned_update_old_row": 98, │ │ │ │ │ + "versioned_rows_w_versionid": 98, │ │ │ │ │ "breviti": 98, │ │ │ │ │ "shrew": 98, │ │ │ │ │ "anim": 98, │ │ │ │ │ "cute": 98, │ │ │ │ │ "weasel": 98, │ │ │ │ │ "poison": 98, │ │ │ │ │ "animalfact": 98, │ │ │ │ │ "custom_manag": 98, │ │ │ │ │ "weather": 98, │ │ │ │ │ "contin": 98, │ │ │ │ │ "spoken": 98, │ │ │ │ │ - "separate_t": 98, │ │ │ │ │ + "separate_databas": 98, │ │ │ │ │ "separate_schema_transl": 98, │ │ │ │ │ "schema_translates_map": 98, │ │ │ │ │ - "separate_databas": 98, │ │ │ │ │ + "separate_t": 98, │ │ │ │ │ "temporal_rang": 98, │ │ │ │ │ "filter_publ": 98, │ │ │ │ │ "demo": 98, │ │ │ │ │ "datafil": 98, │ │ │ │ │ "helloworld": 98, │ │ │ │ │ "local_session_cach": 98, │ │ │ │ │ "datamodel": 98,