--- /srv/reproducible-results/rbuild-debian/r-b-build.CtNO9pZ8/b1/sqlalchemy_2.0.32+ds1-1_armhf.changes +++ /srv/reproducible-results/rbuild-debian/r-b-build.CtNO9pZ8/b2/sqlalchemy_2.0.32+ds1-1_armhf.changes ├── Files │ @@ -1,5 +1,5 @@ │ │ - c5a31f72c3839e639a29d56d1717eed3 3956272 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb │ + 324ad48003c07dbdc32d1c960368c38f 3956332 doc optional python-sqlalchemy-doc_2.0.32+ds1-1_all.deb │ 88c3d6454e6920ef9afc0555ecef5c5d 901840 debug optional python3-sqlalchemy-ext-dbgsym_2.0.32+ds1-1_armhf.deb │ 9b135e646e1d03381b2c4aa72571f002 123464 python optional python3-sqlalchemy-ext_2.0.32+ds1-1_armhf.deb │ 0955e7f12a0b73c1ab8406c88fbab7d2 1196068 python optional python3-sqlalchemy_2.0.32+ds1-1_all.deb ├── python-sqlalchemy-doc_2.0.32+ds1-1_all.deb │ ├── file list │ │ @@ -1,3 +1,3 @@ │ │ -rw-r--r-- 0 0 0 4 2024-08-23 07:52:58.000000 debian-binary │ │ -rw-r--r-- 0 0 0 13924 2024-08-23 07:52:58.000000 control.tar.xz │ │ --rw-r--r-- 0 0 0 3942156 2024-08-23 07:52:58.000000 data.tar.xz │ │ +-rw-r--r-- 0 0 0 3942216 2024-08-23 07:52:58.000000 data.tar.xz │ ├── control.tar.xz │ │ ├── control.tar │ │ │ ├── ./md5sums │ │ │ │ ├── ./md5sums │ │ │ │ │┄ Files differ │ ├── data.tar.xz │ │ ├── data.tar │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_14.html │ │ │ │ @@ -9239,15 +9239,22 @@ │ │ │ │
│ │ │ │

See also

│ │ │ │

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

│ │ │ │
│ │ │ │

References: #4710

│ │ │ │

│ │ │ │ │ │ │ │ -

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

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

  • [engine] [performance]

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

    │ │ │ │ +

    References: #4524

    │ │ │ │ +

    │ │ │ │ +
    • │ │ │ │ +

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

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

    │ │ │ │

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

    │ │ │ │

    References: #5315

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [engine] [performance]

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

    │ │ │ │ -

    References: #4524

    │ │ │ │ -

    │ │ │ │ -
    • │ │ │ │

  • [engine] [bug]

    Revised the Connection.execution_options.schema_translate_map │ │ │ │ feature such that the processing of the SQL statement to receive a specific │ │ │ │ schema name occurs within the execution phase of the statement, rather than │ │ │ │ at the compile phase. This is to support the statement being efficiently │ │ │ │ cached. Previously, the current schema being rendered into the statement │ │ │ │ for a particular run would be considered as part of the cache key itself, │ │ │ │ meaning that for a run against hundreds of schemas, there would be hundreds │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -6355,15 +6355,21 @@ │ │ │ │ │ returned by the ResultProxy is now the LegacyRow subclass, which maintains │ │ │ │ │ mapping/tuple hybrid behavior, however the base _R_o_w class now behaves more │ │ │ │ │ fully like a named tuple. │ │ │ │ │ See also │ │ │ │ │ _R_o_w_P_r_o_x_y_ _i_s_ _n_o_ _l_o_n_g_e_r_ _a_ _“_p_r_o_x_y_”_;_ _i_s_ _n_o_w_ _c_a_l_l_e_d_ _R_o_w_ _a_n_d_ _b_e_h_a_v_e_s_ _l_i_k_e_ _a_n_ _e_n_h_a_n_c_e_d │ │ │ │ │ _n_a_m_e_d_ _t_u_p_l_e │ │ │ │ │ References: _#_4_7_1_0 │ │ │ │ │ -[[eennggiinnee]] [[cchhaannggee]] [[ppeerrffoorrmmaannccee]] [[ppyy33kk]] _¶ │ │ │ │ │ +[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] _¶ │ │ │ │ │ +The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ │ +connection that was just opened in the same checkout operation. pre ping only │ │ │ │ │ +applies to a DBAPI connection that’s been checked into the pool and is being │ │ │ │ │ +checked out again. │ │ │ │ │ +References: _#_4_5_2_4 │ │ │ │ │ +[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] [[cchhaannggee]] [[ppyy33kk]] _¶ │ │ │ │ │ Disabled the “unicode returns” check that runs on dialect startup when running │ │ │ │ │ under Python 3, which for many years has occurred in order to test the current │ │ │ │ │ DBAPI’s behavior for whether or not it returns Python Unicode or Py2K strings │ │ │ │ │ for the VARCHAR and NVARCHAR datatypes. The check still occurs by default under │ │ │ │ │ Python 2, however the mechanism to test the behavior will be removed in │ │ │ │ │ SQLAlchemy 2.0 when Python 2 support is also removed. │ │ │ │ │ This logic was very effective when it was needed, however now that Python 3 is │ │ │ │ │ @@ -6371,20 +6377,14 @@ │ │ │ │ │ datatypes. In the unlikely case that a third party DBAPI does not support this, │ │ │ │ │ the conversion logic within _S_t_r_i_n_g is still available and the third party │ │ │ │ │ dialect may specify this in its upfront dialect flags by setting the dialect │ │ │ │ │ level flag returns_unicode_strings to one of String.RETURNS_CONDITIONAL or │ │ │ │ │ String.RETURNS_BYTES, both of which will enable Unicode conversion even under │ │ │ │ │ Python 3. │ │ │ │ │ References: _#_5_3_1_5 │ │ │ │ │ -[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] _¶ │ │ │ │ │ -The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ │ -connection that was just opened in the same checkout operation. pre ping only │ │ │ │ │ -applies to a DBAPI connection that’s been checked into the pool and is being │ │ │ │ │ -checked out again. │ │ │ │ │ -References: _#_4_5_2_4 │ │ │ │ │ [[eennggiinnee]] [[bbuugg]] _¶ │ │ │ │ │ Revised the _C_o_n_n_e_c_t_i_o_n_._e_x_e_c_u_t_i_o_n___o_p_t_i_o_n_s_._s_c_h_e_m_a___t_r_a_n_s_l_a_t_e___m_a_p feature such that │ │ │ │ │ the processing of the SQL statement to receive a specific schema name occurs │ │ │ │ │ within the execution phase of the statement, rather than at the compile phase. │ │ │ │ │ This is to support the statement being efficiently cached. Previously, the │ │ │ │ │ current schema being rendered into the statement for a particular run would be │ │ │ │ │ considered as part of the cache key itself, meaning that for a run against │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_20.html │ │ │ │ @@ -7935,31 +7935,31 @@ │ │ │ │

    │ │ │ │
    • │ │ │ │

  • [sqlite] [usecase]

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

    │ │ │ │

    References: #6195

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [sqlite] [usecase] [performance]

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

  • [sqlite] [usecase]

    The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements │ │ │ │ +that may refer to additional tables within the WHERE criteria of the │ │ │ │ +statement without the need to use subqueries. This syntax is invoked │ │ │ │ +automatically when using the Update construct when more than │ │ │ │ +one table or other entity or selectable is used.

    │ │ │ │ +

    References: #7185

    │ │ │ │ +

    │ │ │ │ +
    • │ │ │ │ +

  • [sqlite] [performance] [usecase]

    SQLite datetime, date, and time datatypes now use Python standard lib │ │ │ │ fromisoformat() methods in order to parse incoming datetime, date, and │ │ │ │ time string values. This improves performance vs. the previous regular │ │ │ │ expression-based approach, and also automatically accommodates for datetime │ │ │ │ and time formats that contain either a six-digit “microseconds” format or a │ │ │ │ three-digit “milliseconds” format.

    │ │ │ │

    References: #7029

    │ │ │ │

    │ │ │ │
    • │ │ │ │ -

  • [sqlite] [usecase]

    The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements │ │ │ │ -that may refer to additional tables within the WHERE criteria of the │ │ │ │ -statement without the need to use subqueries. This syntax is invoked │ │ │ │ -automatically when using the Update construct when more than │ │ │ │ -one table or other entity or selectable is used.

    │ │ │ │ -

    References: #7185

    │ │ │ │ -

    │ │ │ │ -
    • │ │ │ │

  • [sqlite] [bug]

    Removed the warning that emits from the Numeric type about │ │ │ │ DBAPIs not supporting Decimal values natively. This warning was oriented │ │ │ │ towards SQLite, which does not have any real way without additional │ │ │ │ extensions or workarounds of handling precision numeric values more than 15 │ │ │ │ significant digits as it only uses floating point math to represent │ │ │ │ numbers. As this is a known and documented limitation in SQLite itself, and │ │ │ │ not a quirk of the pysqlite driver, there’s no need for SQLAlchemy to warn │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -5471,29 +5471,29 @@ │ │ │ │ │ See also │ │ │ │ │ _R_e_f_l_e_c_t_i_n_g_ _i_n_t_e_r_n_a_l_ _s_c_h_e_m_a_ _t_a_b_l_e_s │ │ │ │ │ References: _#_8_2_3_4 │ │ │ │ │ [[ssqqlliittee]] [[uusseeccaassee]] _¶ │ │ │ │ │ Added RETURNING support for the SQLite dialect. SQLite supports RETURNING since │ │ │ │ │ version 3.35. │ │ │ │ │ References: _#_6_1_9_5 │ │ │ │ │ -[[ssqqlliittee]] [[uusseeccaassee]] [[ppeerrffoorrmmaannccee]] _¶ │ │ │ │ │ -SQLite datetime, date, and time datatypes now use Python standard lib │ │ │ │ │ -fromisoformat() methods in order to parse incoming datetime, date, and time │ │ │ │ │ -string values. This improves performance vs. the previous regular expression- │ │ │ │ │ -based approach, and also automatically accommodates for datetime and time │ │ │ │ │ -formats that contain either a six-digit “microseconds” format or a three-digit │ │ │ │ │ -“milliseconds” format. │ │ │ │ │ -References: _#_7_0_2_9 │ │ │ │ │ [[ssqqlliittee]] [[uusseeccaassee]] _¶ │ │ │ │ │ The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements that │ │ │ │ │ may refer to additional tables within the WHERE criteria of the statement │ │ │ │ │ without the need to use subqueries. This syntax is invoked automatically when │ │ │ │ │ using the _U_p_d_a_t_e construct when more than one table or other entity or │ │ │ │ │ selectable is used. │ │ │ │ │ References: _#_7_1_8_5 │ │ │ │ │ +[[ssqqlliittee]] [[ppeerrffoorrmmaannccee]] [[uusseeccaassee]] _¶ │ │ │ │ │ +SQLite datetime, date, and time datatypes now use Python standard lib │ │ │ │ │ +fromisoformat() methods in order to parse incoming datetime, date, and time │ │ │ │ │ +string values. This improves performance vs. the previous regular expression- │ │ │ │ │ +based approach, and also automatically accommodates for datetime and time │ │ │ │ │ +formats that contain either a six-digit “microseconds” format or a three-digit │ │ │ │ │ +“milliseconds” format. │ │ │ │ │ +References: _#_7_0_2_9 │ │ │ │ │ [[ssqqlliittee]] [[bbuugg]] _¶ │ │ │ │ │ Removed the warning that emits from the _N_u_m_e_r_i_c type about DBAPIs not │ │ │ │ │ supporting Decimal values natively. This warning was oriented towards SQLite, │ │ │ │ │ which does not have any real way without additional extensions or workarounds │ │ │ │ │ of handling precision numeric values more than 15 significant digits as it only │ │ │ │ │ uses floating point math to represent numbers. As this is a known and │ │ │ │ │ documented limitation in SQLite itself, and not a quirk of the pysqlite driver, │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html │ │ │ │┄ Ordering differences only │ │ │ │ @@ -299,42 +299,42 @@ │ │ │ │ │ │ │ │

    │ │ │ │

    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:

    │ │ │ │

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

    Asyncio Integration

    │ │ │ │

    Examples illustrating the asyncio engine feature of SQLAlchemy.

    │ │ │ │

    Listing of files:

    │ │ │ │

    │ │ │ │
    │ │ │ │ │ │ │ │ @@ -817,40 +817,40 @@ │ │ │ │
    │ │ │ │

    Basic Inheritance Mappings

    │ │ │ │

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

    │ │ │ │

    Listing of files:

    │ │ │ │

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

    Special APIs

    │ │ │ │
    │ │ │ │

    Attribute Instrumentation

    │ │ │ │

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

    │ │ │ │

    Listing of files:

    │ │ │ │

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

    Horizontal Sharding

    │ │ │ │

    A basic example of using the SQLAlchemy Sharding API. │ │ │ │ Sharding refers to horizontally scaling data across multiple │ │ │ │ @@ -884,19 +884,19 @@ │ │ │ │ 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.

      │ │ │ │

      • │ │ │ │ +

    • asyncio.py - Illustrates sharding API used with asyncio.

      │ │ │ │ +

      • │ │ │ │

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

      │ │ │ │

      • │ │ │ │ -

    • asyncio.py - Illustrates sharding API used with asyncio.

      │ │ │ │ -

      • │ │ │ │
    │ │ │ │

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

    Extending the ORM

    │ │ │ │
    │ │ │ │ @@ -907,19 +907,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 {} │ │ │ │ │ @@ -96,32 +96,33 @@ │ │ │ │ │ Listing of files: │ │ │ │ │ * _a_d_j_a_c_e_n_c_y___l_i_s_t_._p_y │ │ │ │ │ ******** AAssssoocciiaattiioonnss_?¶ ******** │ │ │ │ │ Examples illustrating the usage of the “association object” pattern, where an │ │ │ │ │ intermediary class mediates the relationship between two classes that are │ │ │ │ │ associated in a many-to-many pattern. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _b_a_s_i_c___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrate a many-to-many relationship between an │ │ │ │ │ - “Order” and a collection of “Item” objects, associating a purchase price │ │ │ │ │ - with each via an association object called “OrderItem” │ │ │ │ │ + * _d_i_c_t___o_f___s_e_t_s___w_i_t_h___d_e_f_a_u_l_t_._p_y - An advanced association proxy example │ │ │ │ │ + which illustrates nesting of association proxies to produce multi-level │ │ │ │ │ + Python collections, in this case a dictionary with string keys and sets │ │ │ │ │ + of integers as values, which conceal the underlying mapped classes. │ │ │ │ │ +_b_a_s_i_c___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrate a many-to-many relationship between an │ │ │ │ │ +“Order” and a collection of “Item” objects, associating a purchase price with │ │ │ │ │ +each via an association object called “OrderItem” │ │ │ │ │ _p_r_o_x_i_e_d___a_s_s_o_c_i_a_t_i_o_n_._p_y - Same example as basic_association, adding in usage of │ │ │ │ │ _s_q_l_a_l_c_h_e_m_y_._e_x_t_._a_s_s_o_c_i_a_t_i_o_n_p_r_o_x_y to make explicit references to OrderItem │ │ │ │ │ optional. │ │ │ │ │ -_d_i_c_t___o_f___s_e_t_s___w_i_t_h___d_e_f_a_u_l_t_._p_y - An advanced association proxy example which │ │ │ │ │ -illustrates nesting of association proxies to produce multi-level Python │ │ │ │ │ -collections, in this case a dictionary with string keys and sets of integers as │ │ │ │ │ -values, which conceal the underlying mapped classes. │ │ │ │ │ ******** AAssyynncciioo IInntteeggrraattiioonn_?¶ ******** │ │ │ │ │ Examples illustrating the asyncio engine feature of SQLAlchemy. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _a_s_y_n_c___o_r_m___w_r_i_t_e_o_n_l_y_._p_y - Illustrates using wwrriittee oonnllyy rreellaattiioonnsshhiippss for │ │ │ │ │ - simpler handling of ORM collections under asyncio. │ │ │ │ │ -_g_r_e_e_n_l_e_t___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ -object for asynchronous ORM use, including the optional run_sync() method. │ │ │ │ │ + * _g_r_e_e_n_l_e_t___o_r_m_._p_y - Illustrates use of the │ │ │ │ │ + sqlalchemy.ext.asyncio.AsyncSession object for asynchronous ORM use, │ │ │ │ │ + including the optional run_sync() method. │ │ │ │ │ _b_a_s_i_c_._p_y - Illustrates the asyncio engine / connection interface. │ │ │ │ │ +_a_s_y_n_c___o_r_m___w_r_i_t_e_o_n_l_y_._p_y - Illustrates using wwrriittee oonnllyy rreellaattiioonnsshhiippss for simpler │ │ │ │ │ +handling of ORM collections under asyncio. │ │ │ │ │ _a_s_y_n_c___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ object for asynchronous ORM use. │ │ │ │ │ _g_a_t_h_e_r___o_r_m___s_t_a_t_e_m_e_n_t_s_._p_y - Illustrates how to run many statements concurrently │ │ │ │ │ using asyncio.gather() along many asyncio database connections, merging ORM │ │ │ │ │ results into a single AsyncSession. │ │ │ │ │ ******** DDiirreecctteedd GGrraapphhss_?¶ ******** │ │ │ │ │ An example of persistence for a directed graph structure. The graph is stored │ │ │ │ │ @@ -220,29 +221,29 @@ │ │ │ │ │ $ python -m examples.performance bulk_inserts \ │ │ │ │ │ --dburl mysql+mysqldb://scott:tiger@localhost/test \ │ │ │ │ │ --profile --num 1000 │ │ │ │ │ See also │ │ │ │ │ _H_o_w_ _c_a_n_ _I_ _p_r_o_f_i_l_e_ _a_ _S_Q_L_A_l_c_h_e_m_y_ _p_o_w_e_r_e_d_ _a_p_p_l_i_c_a_t_i_o_n_? │ │ │ │ │ ****** FFiillee LLiissttiinngg_?¶ ****** │ │ │ │ │ Listing of files: │ │ │ │ │ - * _s_i_n_g_l_e___i_n_s_e_r_t_s_._p_y - In this series of tests, we’re looking at a method │ │ │ │ │ - that inserts a row within a distinct transaction, and afterwards returns │ │ │ │ │ - to essentially a “closed” state. This would be analogous to an API call │ │ │ │ │ - that starts up a database connection, inserts the row, commits and │ │ │ │ │ - closes. │ │ │ │ │ -_s_h_o_r_t___s_e_l_e_c_t_s_._p_y - This series of tests illustrates different ways to SELECT a │ │ │ │ │ -single record by primary key │ │ │ │ │ + * _____m_a_i_n_____._p_y - Allows the examples/performance package to be run as a │ │ │ │ │ + script. │ │ │ │ │ +_s_i_n_g_l_e___i_n_s_e_r_t_s_._p_y - In this series of tests, we’re looking at a method that │ │ │ │ │ +inserts a row within a distinct transaction, and afterwards returns to │ │ │ │ │ +essentially a “closed” state. This would be analogous to an API call that │ │ │ │ │ +starts up a database connection, inserts the row, commits and closes. │ │ │ │ │ _b_u_l_k___u_p_d_a_t_e_s_._p_y - This series of tests will illustrate different ways to UPDATE │ │ │ │ │ a large number of rows in bulk (under construction! there’s just one test at │ │ │ │ │ the moment) │ │ │ │ │ -_l_a_r_g_e___r_e_s_u_l_t_s_e_t_s_._p_y - In this series of tests, we are looking at time to load a │ │ │ │ │ -large number of very small and simple rows. │ │ │ │ │ -_____m_a_i_n_____._p_y - Allows the examples/performance package to be run as a script. │ │ │ │ │ _b_u_l_k___i_n_s_e_r_t_s_._p_y - This series of tests illustrates different ways to INSERT a │ │ │ │ │ large number of rows in bulk. │ │ │ │ │ +_l_a_r_g_e___r_e_s_u_l_t_s_e_t_s_._p_y - In this series of tests, we are looking at time to load a │ │ │ │ │ +large number of very small and simple rows. │ │ │ │ │ +_s_h_o_r_t___s_e_l_e_c_t_s_._p_y - This series of tests illustrates different ways to SELECT a │ │ │ │ │ +single record by primary key │ │ │ │ │ ****** RRuunnnniinngg aallll tteessttss wwiitthh ttiimmee_?¶ ****** │ │ │ │ │ This is the default form of run: │ │ │ │ │ $ python -m examples.performance single_inserts │ │ │ │ │ Tests to run: test_orm_commit, test_bulk_save, │ │ │ │ │ test_bulk_insert_dictionaries, test_core, │ │ │ │ │ test_core_query_caching, test_dbapi_raw_w_connect, │ │ │ │ │ test_dbapi_raw_w_pool │ │ │ │ │ @@ -476,20 +477,20 @@ │ │ │ │ │ technique of versioned_rows.py, but also emits an UPDATE on the oolldd row │ │ │ │ │ to affect a change in timestamp. Also includes a │ │ │ │ │ _S_e_s_s_i_o_n_E_v_e_n_t_s_._d_o___o_r_m___e_x_e_c_u_t_e_(_) hook to limit queries to only the most │ │ │ │ │ recent version. │ │ │ │ │ _v_e_r_s_i_o_n_e_d___m_a_p_._p_y - A variant of the versioned_rows example built around the │ │ │ │ │ concept of a “vertical table” structure, like those illustrated in _V_e_r_t_i_c_a_l │ │ │ │ │ _A_t_t_r_i_b_u_t_e_ _M_a_p_p_i_n_g examples. │ │ │ │ │ -_v_e_r_s_i_o_n_e_d___r_o_w_s_._p_y - Illustrates a method to intercept changes on objects, │ │ │ │ │ -turning an UPDATE statement on a single row into an INSERT statement, so that a │ │ │ │ │ -new row is inserted with the new data, keeping the old row intact. │ │ │ │ │ _v_e_r_s_i_o_n_e_d___r_o_w_s___w___v_e_r_s_i_o_n_i_d_._p_y - Illustrates a method to intercept changes on │ │ │ │ │ objects, turning an UPDATE statement on a single row into an INSERT statement, │ │ │ │ │ so that a new row is inserted with the new data, keeping the old row intact. │ │ │ │ │ +_v_e_r_s_i_o_n_e_d___r_o_w_s_._p_y - Illustrates a method to intercept changes on objects, │ │ │ │ │ +turning an UPDATE statement on a single row into an INSERT statement, so that a │ │ │ │ │ +new row is inserted with the new data, keeping the old row intact. │ │ │ │ │ ******** VVeerrttiiccaall AAttttrriibbuuttee MMaappppiinngg_?¶ ******** │ │ │ │ │ Illustrates “vertical table” mappings. │ │ │ │ │ A “vertical table” refers to a technique where individual attributes of an │ │ │ │ │ object are stored as distinct rows in a table. The “vertical table” technique │ │ │ │ │ is used to persist objects which can have a varied set of attributes, at the │ │ │ │ │ expense of simple query control and brevity. It is commonly found in content/ │ │ │ │ │ document management systems in order to represent user-created structures │ │ │ │ │ @@ -517,28 +518,28 @@ │ │ │ │ │ dictionary. │ │ │ │ │ ********** IInnhheerriittaannccee MMaappppiinngg RReecciippeess_?¶ ********** │ │ │ │ │ ******** BBaassiicc IInnhheerriittaannccee MMaappppiinnggss_?¶ ******** │ │ │ │ │ Working examples of single-table, joined-table, and concrete-table inheritance │ │ │ │ │ as described in _M_a_p_p_i_n_g_ _C_l_a_s_s_ _I_n_h_e_r_i_t_a_n_c_e_ _H_i_e_r_a_r_c_h_i_e_s. │ │ │ │ │ Listing of files: │ │ │ │ │ * _c_o_n_c_r_e_t_e_._p_y - Concrete-table (table-per-class) inheritance example. │ │ │ │ │ -_j_o_i_n_e_d_._p_y - Joined-table (table-per-subclass) inheritance example. │ │ │ │ │ _s_i_n_g_l_e_._p_y - Single-table (table-per-hierarchy) inheritance example. │ │ │ │ │ +_j_o_i_n_e_d_._p_y - Joined-table (table-per-subclass) inheritance example. │ │ │ │ │ ********** SSppeecciiaall AAPPIIss_?¶ ********** │ │ │ │ │ ******** AAttttrriibbuuttee IInnssttrruummeennttaattiioonn_?¶ ******** │ │ │ │ │ Examples illustrating modifications to SQLAlchemy’s attribute management │ │ │ │ │ system. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _l_i_s_t_e_n___f_o_r___e_v_e_n_t_s_._p_y - Illustrates how to attach events to all │ │ │ │ │ - instrumented attributes and listen for change events. │ │ │ │ │ + * _c_u_s_t_o_m___m_a_n_a_g_e_m_e_n_t_._p_y - Illustrates customized class instrumentation, │ │ │ │ │ + using the _s_q_l_a_l_c_h_e_m_y_._e_x_t_._i_n_s_t_r_u_m_e_n_t_a_t_i_o_n extension package. │ │ │ │ │ +_l_i_s_t_e_n___f_o_r___e_v_e_n_t_s_._p_y - Illustrates how to attach events to all instrumented │ │ │ │ │ +attributes and listen for change events. │ │ │ │ │ _a_c_t_i_v_e___c_o_l_u_m_n___d_e_f_a_u_l_t_s_._p_y - Illustrates use of the _A_t_t_r_i_b_u_t_e_E_v_e_n_t_s_._i_n_i_t___s_c_a_l_a_r │ │ │ │ │ _(_) event, in conjunction with Core column defaults to provide ORM objects that │ │ │ │ │ automatically produce the default value when an un-set attribute is accessed. │ │ │ │ │ -_c_u_s_t_o_m___m_a_n_a_g_e_m_e_n_t_._p_y - Illustrates customized class instrumentation, using the │ │ │ │ │ -_s_q_l_a_l_c_h_e_m_y_._e_x_t_._i_n_s_t_r_u_m_e_n_t_a_t_i_o_n extension package. │ │ │ │ │ ******** HHoorriizzoonnttaall SShhaarrddiinngg_?¶ ******** │ │ │ │ │ A basic example of using the SQLAlchemy Sharding API. Sharding refers to │ │ │ │ │ horizontally scaling data across multiple databases. │ │ │ │ │ The basic components of a “sharded” mapping are: │ │ │ │ │ * multiple _E_n_g_i_n_e instances, each assigned a “shard id”. These _E_n_g_i_n_e │ │ │ │ │ instances may refer to different databases, or different schemas / │ │ │ │ │ accounts within the same database, or they can even be differentiated │ │ │ │ │ @@ -563,32 +564,32 @@ │ │ │ │ │ objects to different tables (and potentially database nodes) in an explicit way │ │ │ │ │ - described on the wiki at _E_n_t_i_t_y_N_a_m_e. │ │ │ │ │ Listing of files: │ │ │ │ │ * _s_e_p_a_r_a_t_e___d_a_t_a_b_a_s_e_s_._p_y - Illustrates sharding using distinct SQLite │ │ │ │ │ databases. │ │ │ │ │ _s_e_p_a_r_a_t_e___t_a_b_l_e_s_._p_y - Illustrates sharding using a single SQLite database, that │ │ │ │ │ will however have multiple tables using a naming convention. │ │ │ │ │ +_a_s_y_n_c_i_o_._p_y - Illustrates sharding API used with asyncio. │ │ │ │ │ _s_e_p_a_r_a_t_e___s_c_h_e_m_a___t_r_a_n_s_l_a_t_e_s_._p_y - Illustrates sharding using a single database │ │ │ │ │ with multiple schemas, where a different “schema_translates_map” can be used │ │ │ │ │ for each shard. │ │ │ │ │ -_a_s_y_n_c_i_o_._p_y - Illustrates sharding API used with asyncio. │ │ │ │ │ ********** EExxtteennddiinngg tthhee OORRMM_?¶ ********** │ │ │ │ │ ******** OORRMM QQuueerryy EEvveennttss_?¶ ******** │ │ │ │ │ Recipes which illustrate augmentation of ORM SELECT behavior as used by │ │ │ │ │ _S_e_s_s_i_o_n_._e_x_e_c_u_t_e_(_) with _2_._0_ _s_t_y_l_e use of _s_e_l_e_c_t_(_), as well as the _1_._x_ _s_t_y_l_e │ │ │ │ │ _Q_u_e_r_y object. │ │ │ │ │ Examples include demonstrations of the _w_i_t_h___l_o_a_d_e_r___c_r_i_t_e_r_i_a_(_) option as well as │ │ │ │ │ the _S_e_s_s_i_o_n_E_v_e_n_t_s_._d_o___o_r_m___e_x_e_c_u_t_e_(_) hook. │ │ │ │ │ As of SQLAlchemy 1.4, the _Q_u_e_r_y construct is unified with the _S_e_l_e_c_t construct, │ │ │ │ │ so that these two objects are mostly the same. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _f_i_l_t_e_r___p_u_b_l_i_c_._p_y - Illustrates a global criteria applied to entities of a │ │ │ │ │ - particular type. │ │ │ │ │ -_t_e_m_p_o_r_a_l___r_a_n_g_e_._p_y - Illustrates a custom per-query criteria that will be │ │ │ │ │ -applied to selected entities. │ │ │ │ │ + * _t_e_m_p_o_r_a_l___r_a_n_g_e_._p_y - Illustrates a custom per-query criteria that will be │ │ │ │ │ + applied to selected entities. │ │ │ │ │ +_f_i_l_t_e_r___p_u_b_l_i_c_._p_y - Illustrates a global criteria applied to entities of a │ │ │ │ │ +particular type. │ │ │ │ │ ******** DDooggppiillee CCaacchhiinngg_?¶ ******** │ │ │ │ │ Illustrates how to embed _d_o_g_p_i_l_e_._c_a_c_h_e 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 _S_e_s_s_i_o_n_E_v_e_n_t_s_._d_o___o_r_m___e_x_e_c_u_t_e_(_) event hook │ │ │ │ │ * Basic technique of circumventing _S_e_s_s_i_o_n_._e_x_e_c_u_t_e_(_) to pull from a custom