--- /srv/reproducible-results/rbuild-debian/r-b-build.ODddrMmb/b1/sqlalchemy_1.4.50+ds1-1_i386.changes +++ /srv/reproducible-results/rbuild-debian/r-b-build.ODddrMmb/b2/sqlalchemy_1.4.50+ds1-1_i386.changes ├── Files │ @@ -1,5 +1,5 @@ │ │ - e2b00e528839e5301f19c335c12aad90 3719988 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb │ + 034143d3b673d02ed73a1ba5a1b7f1fc 3720236 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb │ a35a05381daf16b69a8c4e74b15c6441 62104 debug optional python3-sqlalchemy-ext-dbgsym_1.4.50+ds1-1_i386.deb │ af1e87ed481dbbc93c449748c4af29ce 21488 python optional python3-sqlalchemy-ext_1.4.50+ds1-1_i386.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 13368 2024-01-05 13:47:47.000000 control.tar.xz │ │ --rw-r--r-- 0 0 0 3706428 2024-01-05 13:47:47.000000 data.tar.xz │ │ +-rw-r--r-- 0 0 0 13380 2024-01-05 13:47:47.000000 control.tar.xz │ │ +-rw-r--r-- 0 0 0 3706664 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] [performance] [bug] [py2k]

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

  • [oracle] [bug] [performance] [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 {} │ │ │ │ │ @@ -333,15 +333,15 @@ │ │ │ │ │ # oracle │ │ │ │ │ # tests │ │ │ │ │ # misc │ │ │ │ │ ****** 1.0 Changelog¶ ****** │ │ │ │ │ ***** 1.0.19¶ ***** │ │ │ │ │ Released: August 3, 2017 │ │ │ │ │ **** oracle¶ **** │ │ │ │ │ - * [oracle] [performance] [bug] [py2k] ¶ │ │ │ │ │ + * [oracle] [bug] [performance] [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 │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_11.html │ │ │ │ @@ -875,15 +875,15 @@ │ │ │ │

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

1.1.13

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

oracle

│ │ │ │
    │ │ │ │ -

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

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

  • [oracle] [bug] [performance] [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 {} │ │ │ │ │ @@ -529,15 +529,15 @@ │ │ │ │ │ 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: #4053 │ │ │ │ │ │ │ │ │ │ ***** 1.1.13¶ ***** │ │ │ │ │ Released: August 3, 2017 │ │ │ │ │ **** oracle¶ **** │ │ │ │ │ - * [oracle] [performance] [bug] [py2k] ¶ │ │ │ │ │ + * [oracle] [bug] [performance] [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 │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_12.html │ │ │ │ @@ -2979,15 +2979,15 @@ │ │ │ │

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

oracle

│ │ │ │
    │ │ │ │ -

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

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

  • [oracle] [bug] [performance] [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 {} │ │ │ │ │ @@ -2003,15 +2003,15 @@ │ │ │ │ │ [mssql] [bug] ¶ │ │ │ │ │ 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: #4059 │ │ │ │ │ │ │ │ │ │ **** oracle¶ **** │ │ │ │ │ - * [oracle] [performance] [bug] [py2k] ¶ │ │ │ │ │ + * [oracle] [bug] [performance] [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 │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_13.html │ │ │ │ @@ -1803,30 +1803,30 @@ │ │ │ │

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

oracle

│ │ │ │
    │ │ │ │ -

  • [oracle] [performance] [bug]

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

  • [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 │ │ │ │ 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

      │ │ │ │

      │ │ │ │
      • │ │ │ │ -

    • [performance] [bug]

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

    • [bug] [performance]

      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 {} │ │ │ │ │ @@ -1214,28 +1214,28 @@ │ │ │ │ │ [mssql] [bug] [reflection] ¶ │ │ │ │ │ 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: #5271 │ │ │ │ │ │ │ │ │ │ **** oracle¶ **** │ │ │ │ │ - * [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 │ │ │ │ │ + * [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 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 │ │ │ │ │ │ │ │ │ │ **** firebird¶ **** │ │ │ │ │ * [firebird] [change] ¶ │ │ │ │ │ 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: #5278 │ │ │ │ │ @@ -1501,15 +1501,15 @@ │ │ │ │ │ References: #5146 │ │ │ │ │ │ │ │ │ │ **** 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 │ │ │ │ │ -[performance] [bug] ¶ │ │ │ │ │ +[bug] [performance] ¶ │ │ │ │ │ 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 │ │ │ ├── ./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] [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 │ │ │ │ +

    • [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] [performance] [bug]

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

  • [oracle] [bug] [performance]

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

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

1.4.18

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

orm

│ │ │ │
    │ │ │ │ -

  • [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 │ │ │ │ +

  • [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 │ │ │ │ @@ -5361,29 +5352,38 @@ │ │ │ │ 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] [performance] [bug] [regression] [sql]

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

  • [orm] [bug] [performance] [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,22 +9028,15 @@ │ │ │ │

    │ │ │ │

    See also

    │ │ │ │

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

    │ │ │ │
    │ │ │ │

    References: #4710

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [engine] [performance]

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

    │ │ │ │ -

    References: #4524

    │ │ │ │ -

    │ │ │ │ -
    • │ │ │ │ -

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

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

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

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

    │ │ │ │

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

    │ │ │ │

    References: #5315

    │ │ │ │

    │ │ │ │
    • │ │ │ │ +

  • [engine] [performance]

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

    │ │ │ │ +

    References: #4524

    │ │ │ │ +

    │ │ │ │ +
    • │ │ │ │

  • [engine] [bug]

    Revised the Connection.execution_options.schema_translate_map │ │ │ │ feature such that the processing of the SQL statement to receive a specific │ │ │ │ schema name occurs within the execution phase of the statement, rather than │ │ │ │ at the compile phase. This is to support the statement being efficiently │ │ │ │ cached. Previously, the current schema being rendered into the statement │ │ │ │ for a particular run would be considered as part of the cache key itself, │ │ │ │ meaning that for a run against hundreds of schemas, there would be hundreds │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -1998,31 +1998,31 @@ │ │ │ │ │ [orm] [usecase] ¶ │ │ │ │ │ Added new attributes UpdateBase.returning_column_descriptions and │ │ │ │ │ UpdateBase.entity_description to allow for inspection of ORM 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] [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 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 │ │ │ │ │ [orm] [bug] ¶ │ │ │ │ │ @@ -3285,15 +3285,15 @@ │ │ │ │ │ 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: #6910 │ │ │ │ │ │ │ │ │ │ **** oracle¶ **** │ │ │ │ │ - * [oracle] [performance] [bug] ¶ │ │ │ │ │ + * [oracle] [bug] [performance] ¶ │ │ │ │ │ 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. │ │ │ │ │ @@ -3822,50 +3822,51 @@ │ │ │ │ │ “on”; it’s in this directive where the schema translate map would fail to be │ │ │ │ │ honored. │ │ │ │ │ References: #6658 │ │ │ │ │ │ │ │ │ │ ***** 1.4.18¶ ***** │ │ │ │ │ Released: June 10, 2021 │ │ │ │ │ **** orm¶ **** │ │ │ │ │ - * [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 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: #6072, #6487 │ │ │ │ │ + * [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 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: #6072, #6487 │ │ │ │ │ [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 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 relationships would │ │ │ │ │ @@ -4472,15 +4473,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: #6267 │ │ │ │ │ -[orm] [performance] [bug] [regression] [sql] ¶ │ │ │ │ │ +[orm] [bug] [performance] [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 │ │ │ │ │ @@ -6529,21 +6530,15 @@ │ │ │ │ │ returned by the ResultProxy is now the LegacyRow subclass, which maintains │ │ │ │ │ mapping/tuple hybrid behavior, however the base Row class now behaves more │ │ │ │ │ fully like a named tuple. │ │ │ │ │ See also │ │ │ │ │ RowProxy_is_no_longer_a_“proxy”;_is_now_called_Row_and_behaves_like_an_enhanced │ │ │ │ │ named_tuple │ │ │ │ │ References: #4710 │ │ │ │ │ -[engine] [performance] ¶ │ │ │ │ │ -The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ │ -connection that was just opened in the same checkout operation. pre ping only │ │ │ │ │ -applies to a DBAPI connection that’s been checked into the pool and is being │ │ │ │ │ -checked out again. │ │ │ │ │ -References: #4524 │ │ │ │ │ -[engine] [performance] [change] [py3k] ¶ │ │ │ │ │ +[engine] [change] [performance] [py3k] ¶ │ │ │ │ │ Disabled the “unicode returns” check that runs on dialect startup when running │ │ │ │ │ under Python 3, which for many years has occurred in order to test the current │ │ │ │ │ DBAPI’s behavior for whether or not it returns Python Unicode or Py2K strings │ │ │ │ │ for the VARCHAR and NVARCHAR datatypes. The check still occurs by default under │ │ │ │ │ Python 2, however the mechanism to test the behavior will be removed in │ │ │ │ │ SQLAlchemy 2.0 when Python 2 support is also removed. │ │ │ │ │ This logic was very effective when it was needed, however now that Python 3 is │ │ │ │ │ @@ -6551,14 +6546,20 @@ │ │ │ │ │ datatypes. In the unlikely case that a third party DBAPI does not support this, │ │ │ │ │ the conversion logic within String 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: #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 │ │ │ ├── ./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:

    │ │ │ │ -

  • 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.

    │ │ │ │ -

    • │ │ │ │

  • 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”

    │ │ │ │

    • │ │ │ │

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

    │ │ │ │

    • │ │ │ │ +

  • 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.

    │ │ │ │ +

    • │ │ │ │
│ │ │ │

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

Asyncio Integration

│ │ │ │

Examples illustrating the asyncio engine feature of SQLAlchemy.

│ │ │ │

Listing of files:

    │ │ │ │ -

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

    │ │ │ │ -

    • │ │ │ │

  • 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.

    │ │ │ │

    • │ │ │ │ +

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

    │ │ │ │ +

    • │ │ │ │ +

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

    │ │ │ │ +

    • │ │ │ │
│ │ │ │

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

Directed Graphs

│ │ │ │

An example of persistence for a directed graph structure. The │ │ │ │ graph is stored as a collection of edges, each referencing both a │ │ │ │ @@ -391,26 +391,26 @@ │ │ │ │

  • 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.

    │ │ │ │

    • │ │ │ │ +

  • 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.

    │ │ │ │ +

    • │ │ │ │

  • 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.

    │ │ │ │

    • │ │ │ │ │ │ │ │

    │ │ │ │
    │ │ │ │ @@ -500,33 +500,33 @@ │ │ │ │
    │ │ │ │

    See also

    │ │ │ │

    How can I profile a SQLAlchemy powered application?

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

    File Listing

    │ │ │ │

    Listing of files:

      │ │ │ │ -

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

      │ │ │ │ +

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

      │ │ │ │

      • │ │ │ │

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

      │ │ │ │

      • │ │ │ │ -

    • 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.

      │ │ │ │

      • │ │ │ │

    • 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)

      │ │ │ │

      • │ │ │ │ +

    • 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.

      │ │ │ │ +

      • │ │ │ │ +

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

      │ │ │ │ +

      • │ │ │ │
    │ │ │ │

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

    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:

      │ │ │ │ -

    • 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.

      │ │ │ │

      • │ │ │ │ +

    • 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.

      │ │ │ │ +

      • │ │ │ │
    │ │ │ │

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

    Space Invaders

    │ │ │ │

    A Space Invaders game using SQLite as the state machine.

    │ │ │ │

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

    │ │ │ │ @@ -813,19 +813,19 @@ │ │ │ │ assert type(other) is SomeClass and other.id == self.id │ │ │ │ │ │ │ │

    Above, if two instance of SomeClass with the same version identifier │ │ │ │ are updated and sent to the database for UPDATE concurrently, if the database │ │ │ │ isolation level allows the two UPDATE statements to proceed, one will fail │ │ │ │ because it no longer is against the last known version identifier.

    │ │ │ │

    Listing of files:

      │ │ │ │ +

    • history_meta.py - Versioned mixin class and other utilities.

      │ │ │ │ +

      • │ │ │ │

    • test_versioning.py - Unit tests illustrating usage of the history_meta.py │ │ │ │ module functions.

      │ │ │ │

      • │ │ │ │ -

    • history_meta.py - Versioned mixin class and other utilities.

      │ │ │ │ -

      • │ │ │ │
    │ │ │ │

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

    Versioning using Temporal Rows

    │ │ │ │

    Several examples that illustrate the technique of intercepting changes │ │ │ │ that would be first interpreted as an UPDATE on a row, and instead turning │ │ │ │ @@ -879,56 +879,56 @@ │ │ │ │ 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:

      │ │ │ │ -

    • 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.

      │ │ │ │

      • │ │ │ │ -

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

      │ │ │ │ +

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

      │ │ │ │

      • │ │ │ │
    │ │ │ │

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

    Special APIs

    │ │ │ │
    │ │ │ │

    Attribute Instrumentation

    │ │ │ │

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

    │ │ │ │

    Listing of files:

      │ │ │ │ -

    • active_column_defaults.py - Illustrates use of the AttributeEvents.init_scalar() │ │ │ │ -event, in conjunction with Core column defaults to provide │ │ │ │ -ORM objects that automatically produce the default value │ │ │ │ -when an un-set attribute is accessed.

      │ │ │ │ +

    • custom_management.py - Illustrates customized class instrumentation, using │ │ │ │ +the sqlalchemy.ext.instrumentation extension package.

      │ │ │ │

      • │ │ │ │

    • listen_for_events.py - Illustrates how to attach events to all instrumented attributes │ │ │ │ and listen for change events.

      │ │ │ │

      • │ │ │ │ -

    • custom_management.py - Illustrates customized class instrumentation, using │ │ │ │ -the sqlalchemy.ext.instrumentation extension package.

      │ │ │ │ +

    • active_column_defaults.py - Illustrates use of the AttributeEvents.init_scalar() │ │ │ │ +event, in conjunction with Core column defaults to provide │ │ │ │ +ORM objects that automatically produce the default value │ │ │ │ +when an un-set attribute is accessed.

      │ │ │ │

      • │ │ │ │
    │ │ │ │

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

    Horizontal Sharding

    │ │ │ │

    A basic example of using the SQLAlchemy Sharding API. │ │ │ │ @@ -960,20 +960,20 @@ │ │ │ │ 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_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.

      │ │ │ │ -

      • │ │ │ │

    • 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_tables.py - Illustrates sharding using a single SQLite database, that will however │ │ │ │ +have multiple tables using a naming convention.

      │ │ │ │ +

      • │ │ │ │
    │ │ │ │

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

    Extending the ORM

    │ │ │ │
    │ │ │ │ @@ -984,19 +984,19 @@ │ │ │ │ object.

    │ │ │ │

    Examples include demonstrations of the with_loader_criteria() │ │ │ │ option as well as the SessionEvents.do_orm_execute() hook.

    │ │ │ │

    As of SQLAlchemy 1.4, the Query construct is unified │ │ │ │ with the Select construct, so that these two objects │ │ │ │ are mostly the same.

    │ │ │ │

    Listing of files:

      │ │ │ │ -

    • filter_public.py - Illustrates a global criteria applied to entities of a particular type.

      │ │ │ │ -

      • │ │ │ │

    • temporal_range.py - Illustrates a custom per-query criteria that will be applied │ │ │ │ to selected entities.

      │ │ │ │

      • │ │ │ │ +

    • filter_public.py - Illustrates a global criteria applied to entities of a particular type.

      │ │ │ │ +

      • │ │ │ │
    │ │ │ │

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

    Dogpile Caching

    │ │ │ │

    Illustrates how to embed │ │ │ │ dogpile.cache │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -123,37 +123,36 @@ │ │ │ │ │ * adjacency_list.py │ │ │ │ │ │ │ │ │ │ **** 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: │ │ │ │ │ - * 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. │ │ │ │ │ -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” │ │ │ │ │ + * 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” │ │ │ │ │ proxied_association.py - Same example as basic_association, adding in usage of │ │ │ │ │ sqlalchemy.ext.associationproxy to make explicit references to OrderItem │ │ │ │ │ optional. │ │ │ │ │ +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. │ │ │ │ │ │ │ │ │ │ **** Asyncio Integration¶ **** │ │ │ │ │ Examples illustrating the asyncio engine feature of SQLAlchemy. │ │ │ │ │ Listing of files: │ │ │ │ │ - * greenlet_orm.py - Illustrates use of the │ │ │ │ │ - sqlalchemy.ext.asyncio.AsyncSession object for asynchronous ORM use, │ │ │ │ │ - including the optional run_sync() method. │ │ │ │ │ -async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ -object for asynchronous ORM use. │ │ │ │ │ -basic.py - Illustrates the asyncio engine / connection interface. │ │ │ │ │ + * async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ + object for asynchronous ORM use. │ │ │ │ │ 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. │ │ │ │ │ +basic.py - Illustrates the asyncio engine / connection interface. │ │ │ │ │ +greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ +object for asynchronous ORM use, including the optional run_sync() method. │ │ │ │ │ │ │ │ │ │ **** Directed Graphs¶ **** │ │ │ │ │ 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) │ │ │ │ │ @@ -183,23 +182,23 @@ │ │ │ │ │ with_SQLAlchemy. │ │ │ │ │ Listing of files: │ │ │ │ │ * 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. │ │ │ │ │ +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. │ │ │ │ │ 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. │ │ │ │ │ │ │ │ │ │ **** Large Collections¶ **** │ │ │ │ │ Large collection example. │ │ │ │ │ Illustrates the options to use with relationship() when the list of related │ │ │ │ │ @@ -263,29 +262,28 @@ │ │ │ │ │ $ python -m examples.performance bulk_inserts \ │ │ │ │ │ --dburl mysql+mysqldb://scott:tiger@localhost/test \ │ │ │ │ │ --profile --num 1000 │ │ │ │ │ See also │ │ │ │ │ How_can_I_profile_a_SQLAlchemy_powered_application? │ │ │ │ │ *** File Listing¶ *** │ │ │ │ │ Listing of files: │ │ │ │ │ - * __main__.py - Allows the examples/performance package to be run as a │ │ │ │ │ - script. │ │ │ │ │ + * bulk_inserts.py - This series of tests illustrates different ways to │ │ │ │ │ + INSERT a large number of rows in bulk. │ │ │ │ │ short_selects.py - This series of tests illustrates different ways to SELECT a │ │ │ │ │ single record by primary key │ │ │ │ │ -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. │ │ │ │ │ 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) │ │ │ │ │ +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. │ │ │ │ │ +__main__.py - Allows the examples/performance package to be run as a script. │ │ │ │ │ │ │ │ │ │ *** Running all tests with time¶ *** │ │ │ │ │ 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, │ │ │ │ │ @@ -426,20 +424,20 @@ │ │ │ │ │ test_subqueryload : load everything, subquery eager loading. (1000 iterations); │ │ │ │ │ total time 2.977696 sec │ │ │ │ │ │ │ │ │ │ **** 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: │ │ │ │ │ - * 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. │ │ │ │ │ + * 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. │ │ │ │ │ │ │ │ │ │ **** Space Invaders¶ **** │ │ │ │ │ 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: │ │ │ │ │ @@ -545,17 +543,17 @@ │ │ │ │ │ def __eq__(self, other): │ │ │ │ │ assert type(other) is SomeClass and other.id == self.id │ │ │ │ │ Above, if two instance of SomeClass with the same version identifier are │ │ │ │ │ updated and sent to the database for UPDATE concurrently, if the database │ │ │ │ │ isolation level allows the two UPDATE statements to proceed, one will fail │ │ │ │ │ because it no longer is against the last known version identifier. │ │ │ │ │ Listing of files: │ │ │ │ │ - * test_versioning.py - Unit tests illustrating usage of the history_meta.py │ │ │ │ │ - module functions. │ │ │ │ │ -history_meta.py - Versioned mixin class and other utilities. │ │ │ │ │ + * history_meta.py - Versioned mixin class and other utilities. │ │ │ │ │ +test_versioning.py - Unit tests illustrating usage of the history_meta.py │ │ │ │ │ +module functions. │ │ │ │ │ │ │ │ │ │ *** Versioning using Temporal Rows¶ *** │ │ │ │ │ Several examples that illustrate the technique of intercepting changes that │ │ │ │ │ would be first interpreted as an UPDATE on a row, and instead turning it into │ │ │ │ │ an INSERT of a new row, leaving the previous row intact as a historical │ │ │ │ │ version. │ │ │ │ │ Compare to the Versioning_with_a_History_Table example which writes a history │ │ │ │ │ @@ -597,40 +595,39 @@ │ │ │ │ │ │ │ │ │ │ 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.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: │ │ │ │ │ - * 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. │ │ │ │ │ -joined.py - Joined-table (table-per-subclass) inheritance example. │ │ │ │ │ +concrete.py - Concrete-table (table-per-class) inheritance example. │ │ │ │ │ │ │ │ │ │ ***** Special APIs¶ ***** │ │ │ │ │ **** Attribute Instrumentation¶ **** │ │ │ │ │ Examples illustrating modifications to SQLAlchemy’s attribute management │ │ │ │ │ system. │ │ │ │ │ Listing of files: │ │ │ │ │ - * active_column_defaults.py - Illustrates use of the │ │ │ │ │ - AttributeEvents.init_scalar() event, in conjunction with Core column │ │ │ │ │ - defaults to provide ORM objects that automatically produce the default │ │ │ │ │ - value when an un-set attribute is accessed. │ │ │ │ │ + * custom_management.py - Illustrates customized class instrumentation, │ │ │ │ │ + using the sqlalchemy.ext.instrumentation extension package. │ │ │ │ │ listen_for_events.py - Illustrates how to attach events to all instrumented │ │ │ │ │ attributes and listen for change events. │ │ │ │ │ -custom_management.py - Illustrates customized class instrumentation, using the │ │ │ │ │ -sqlalchemy.ext.instrumentation extension package. │ │ │ │ │ +active_column_defaults.py - Illustrates use of the AttributeEvents.init_scalar │ │ │ │ │ +() event, in conjunction with Core column defaults to provide ORM objects that │ │ │ │ │ +automatically produce the default value when an un-set attribute is accessed. │ │ │ │ │ │ │ │ │ │ **** Horizontal Sharding¶ **** │ │ │ │ │ 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 Engine instances, each assigned a “shard id”. These Engine │ │ │ │ │ instances may refer to different databases, or different schemas / │ │ │ │ │ @@ -654,34 +651,34 @@ │ │ │ │ │ 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_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. │ │ │ │ │ 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_tables.py - Illustrates sharding using a single SQLite database, that │ │ │ │ │ +will however have multiple tables using a naming convention. │ │ │ │ │ │ │ │ │ │ ***** Extending the ORM¶ ***** │ │ │ │ │ **** ORM Query Events¶ **** │ │ │ │ │ Recipes which illustrate augmentation of ORM SELECT behavior as used by │ │ │ │ │ Session.execute() with 2.0_style use of select(), as well as the 1.x_style │ │ │ │ │ Query object. │ │ │ │ │ Examples include demonstrations of the with_loader_criteria() option as well as │ │ │ │ │ the SessionEvents.do_orm_execute() hook. │ │ │ │ │ As of SQLAlchemy 1.4, the Query construct is unified with the Select construct, │ │ │ │ │ so that these two objects are mostly the same. │ │ │ │ │ Listing of files: │ │ │ │ │ - * filter_public.py - Illustrates a global criteria applied to entities of a │ │ │ │ │ - particular type. │ │ │ │ │ -temporal_range.py - Illustrates a custom per-query criteria that will be │ │ │ │ │ -applied to selected entities. │ │ │ │ │ + * temporal_range.py - Illustrates a custom per-query criteria that will be │ │ │ │ │ + applied to selected entities. │ │ │ │ │ +filter_public.py - Illustrates a global criteria applied to entities of a │ │ │ │ │ +particular type. │ │ │ │ │ │ │ │ │ │ **** Dogpile Caching¶ **** │ │ │ │ │ Illustrates how to embed dogpile.cache functionality with ORM queries, allowing │ │ │ │ │ full cache control as well as the ability to pull “lazy loaded” attributes from │ │ │ │ │ long term cache. │ │ │ │ │ In this demo, the following techniques are illustrated: │ │ │ │ │ * Using the SessionEvents.do_orm_execute() event 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], │ │ │ │ │ @@ -12471,16 +12471,16 @@ │ │ │ │ │ "n5": 98, │ │ │ │ │ "add_neighbor": 98, │ │ │ │ │ "higher_neighbor": 98, │ │ │ │ │ "directed_graph": 98, │ │ │ │ │ "supplier": 98, │ │ │ │ │ "hasaddress": 98, │ │ │ │ │ "generic_fk": 98, │ │ │ │ │ - "table_per_associ": 98, │ │ │ │ │ "ror": 98, │ │ │ │ │ + "table_per_associ": 98, │ │ │ │ │ "table_per_rel": 98, │ │ │ │ │ "materialized_path": 98, │ │ │ │ │ "nested_set": 98, │ │ │ │ │ "single_insert": 98, │ │ │ │ │ "bulk_upd": 98, │ │ │ │ │ "test_orm_commit": 98, │ │ │ │ │ "test_bulk_insert_dictionari": 98, │ │ │ │ │ @@ -12551,19 +12551,19 @@ │ │ │ │ │ "poison": 98, │ │ │ │ │ "animalfact": 98, │ │ │ │ │ "custom_manag": 98, │ │ │ │ │ "weather": 98, │ │ │ │ │ "contin": 98, │ │ │ │ │ "spoken": 98, │ │ │ │ │ "separate_databas": 98, │ │ │ │ │ - "separate_t": 98, │ │ │ │ │ "separate_schema_transl": 98, │ │ │ │ │ "schema_translates_map": 98, │ │ │ │ │ - "filter_publ": 98, │ │ │ │ │ + "separate_t": 98, │ │ │ │ │ "temporal_rang": 98, │ │ │ │ │ + "filter_publ": 98, │ │ │ │ │ "demo": 98, │ │ │ │ │ "datafil": 98, │ │ │ │ │ "helloworld": 98, │ │ │ │ │ "local_session_cach": 98, │ │ │ │ │ "datamodel": 98, │ │ │ │ │ "postalcod": 98, │ │ │ │ │ "citi": [98, 124, 133],