--- /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 @@
│ │ │ │ Fixed performance regression caused by the fix for #3937 where
│ │ │ │ + Fixed performance regression caused by the fix for #3937 where
│ │ │ │ cx_Oracle as of version 5.3 dropped the Fixed performance regression caused by the fix for #3937 where
│ │ │ │ + Fixed performance regression caused by the fix for #3937 where
│ │ │ │ cx_Oracle as of version 5.3 dropped the Fixed performance regression caused by the fix for #3937 where
│ │ │ │ + Fixed performance regression caused by the fix for #3937 where
│ │ │ │ cx_Oracle as of version 5.3 dropped the Changed the implementation of fetching CLOB and BLOB objects to use
│ │ │ │ + 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: #52461.0 Changelog¶
│ │ │ │ 1.0.19¶
│ │ │ │ Released: August 3, 2017oracle¶
│ │ │ │
│ │ │ │ -
.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, 2017oracle¶
│ │ │ │
│ │ │ │ -
│ │ │ │ .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¶
│ │ │ │
│ │ │ │ -
│ │ │ │ .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¶
│ │ │ │
│ │ │ │ -
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
│ │ │ │ │ │ │ │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
│ │ │ │ - │ │ │ │ -Adjusted dialect loading for firebird://
URIs so the external
│ │ │ │ sqlalchemy-firebird dialect will be used if it has been installed,
│ │ │ │ @@ -2204,15 +2204,15 @@
│ │ │ │
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
│ │ │ │ │ │ │ │Revised an internal change to the test system added as a result of │ │ │ │ +
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 anInsert
,
│ │ │ │ Update
, or Delete
construct. The
│ │ │ │ Select.column_descriptions
accessor is also now implemented for
│ │ │ │ Core-only selectables.
│ │ │ │ References: #7861
│ │ │ │ │ │ │ │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
│ │ │ │ - │ │ │ │ -Fixed regression in “dynamic” loader strategy where the │ │ │ │ +
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
│ │ │ │ │ │ │ │Fixed bug where composite()
attributes would not work in
│ │ │ │ +
Fixed bug where composite()
attributes would not work in
│ │ │ │ conjunction with the selectin_polymorphic()
loader strategy for
│ │ │ │ joined table inheritance.
References: #7801
│ │ │ │ │ │ │ │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
│ │ │ │ + │ │ │ │ +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
│ │ │ │ │ │ │ │Added a CAST(VARCHAR2(128)) to the “table name”, “owner”, and other │ │ │ │ +
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 @@ │ │ │ │
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
│ │ │ │ - │ │ │ │ -Clarified the current purpose of the │ │ │ │ +
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.
Adjusted the means by which classes such as scoped_session
│ │ │ │ +
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
│ │ │ │ │ │ │ │Fixed issue where query production for joinedload against a complex left │ │ │ │ +
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
│ │ │ │ │ │ │ │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
│ │ │ │ + │ │ │ │ +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
│ │ │ │ │ │ │ │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
│ │ │ │ │ │ │ │Fixed a critical performance issue where the traversal of a │ │ │ │ +
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
│ │ │ │ │ │ │ │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
│ │ │ │ - │ │ │ │ -Disabled the “unicode returns” check that runs on dialect startup when │ │ │ │ +
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
│ │ │ │ │ │ │ │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
│ │ │ │ + │ │ │ │ +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 @@
│ │ │ │
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.
│ │ │ │ +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.
│ │ │ │ +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.
│ │ │ │See also
│ │ │ │ │ │ │ │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.
│ │ │ │ +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.
│ │ │ │ -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.
│ │ │ │ +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.
│ │ │ │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.
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.
│ │ │ │ +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.
│ │ │ │ +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],