See also
│ │ │ │RowProxy is no longer a “proxy”; is now called Row and behaves like an enhanced named tuple
│ │ │ │References: #4710
│ │ │ │ │ │ │ │ │ │ │ │ -[engine] [performance] ¶
The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ -connection that was just opened in the same checkout operation. pre ping │ │ │ │ -only applies to a DBAPI connection that’s been checked into the pool │ │ │ │ -and is being checked out again.
│ │ │ │ -References: #4524
│ │ │ │ - │ │ │ │ -[engine] [performance] [change] [py3k] ¶
Disabled the “unicode returns” check that runs on dialect startup when │ │ │ │ +
[engine] [change] [performance] [py3k] ¶
Disabled the “unicode returns” check that runs on dialect startup when │ │ │ │ running under Python 3, which for many years has occurred in order to test │ │ │ │ the current DBAPI’s behavior for whether or not it returns Python Unicode │ │ │ │ or Py2K strings for the VARCHAR and NVARCHAR datatypes. The check still │ │ │ │ occurs by default under Python 2, however the mechanism to test the │ │ │ │ behavior will be removed in SQLAlchemy 2.0 when Python 2 support is also │ │ │ │ removed.
│ │ │ │This logic was very effective when it was needed, however now that Python 3
│ │ │ │ @@ -9054,14 +9047,21 @@
│ │ │ │ dialect flags by setting the dialect level flag returns_unicode_strings
│ │ │ │ to one of String.RETURNS_CONDITIONAL or
│ │ │ │ String.RETURNS_BYTES, both of which will enable Unicode conversion
│ │ │ │ even under Python 3.
References: #5315
│ │ │ │ │ │ │ │[engine] [performance] ¶
The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ │ +connection that was just opened in the same checkout operation. pre ping │ │ │ │ +only applies to a DBAPI connection that’s been checked into the pool │ │ │ │ +and is being checked out again.
│ │ │ │ +References: #4524
│ │ │ │ + │ │ │ │ +[engine] [bug] ¶
Revised the Examples illustrating the usage of the “association object” pattern,
│ │ │ │ where an intermediary class mediates the relationship between two
│ │ │ │ classes that are associated in a many-to-many pattern. Listing of files: basic_association.py - Illustrate a many-to-many relationship between an
│ │ │ │ -“Order” and a collection of “Item” objects, associating a purchase price
│ │ │ │ -with each via an association object called “OrderItem” dict_of_sets_with_default.py - An advanced association proxy example which
│ │ │ │ +illustrates nesting of association proxies to produce multi-level Python
│ │ │ │ +collections, in this case a dictionary with string keys and sets of integers
│ │ │ │ +as values, which conceal the underlying mapped classes.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 {}
│ │ │ │ │ @@ -6223,21 +6223,15 @@
│ │ │ │ │ returned by the ResultProxy is now the _L_e_g_a_c_y_R_o_w subclass, which maintains
│ │ │ │ │ mapping/tuple hybrid behavior, however the base _R_o_w class now behaves more
│ │ │ │ │ fully like a named tuple.
│ │ │ │ │ See also
│ │ │ │ │ _R_o_w_P_r_o_x_y_ _i_s_ _n_o_ _l_o_n_g_e_r_ _a_ _“_p_r_o_x_y_”_;_ _i_s_ _n_o_w_ _c_a_l_l_e_d_ _R_o_w_ _a_n_d_ _b_e_h_a_v_e_s_ _l_i_k_e_ _a_n_ _e_n_h_a_n_c_e_d
│ │ │ │ │ _n_a_m_e_d_ _t_u_p_l_e
│ │ │ │ │ References: _#_4_7_1_0
│ │ │ │ │ -[[eennggiinnee]] [[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]] _¶
│ │ │ │ │ +[[eennggiinnee]] [[cchhaannggee]] [[ppeerrffoorrmmaannccee]] [[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
│ │ │ │ │ @@ -6245,14 +6239,20 @@
│ │ │ │ │ datatypes. In the unlikely case that a third party DBAPI does not support this,
│ │ │ │ │ the conversion logic within _S_t_r_i_n_g is still available and the third party
│ │ │ │ │ dialect may specify this in its upfront dialect flags by setting the dialect
│ │ │ │ │ level flag returns_unicode_strings to one of _S_t_r_i_n_g_._R_E_T_U_R_N_S___C_O_N_D_I_T_I_O_N_A_L or
│ │ │ │ │ _S_t_r_i_n_g_._R_E_T_U_R_N_S___B_Y_T_E_S, both of which will enable Unicode conversion even under
│ │ │ │ │ Python 3.
│ │ │ │ │ References: _#_5_3_1_5
│ │ │ │ │ +[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] _¶
│ │ │ │ │ +The pool “pre-ping” feature has been refined to not invoke for a DBAPI
│ │ │ │ │ +connection that was just opened in the same checkout operation. pre ping only
│ │ │ │ │ +applies to a DBAPI connection that’s been checked into the pool and is being
│ │ │ │ │ +checked out again.
│ │ │ │ │ +References: _#_4_5_2_4
│ │ │ │ │ [[eennggiinnee]] [[bbuugg]] _¶
│ │ │ │ │ Revised the _C_o_n_n_e_c_t_i_o_n_._e_x_e_c_u_t_i_o_n___o_p_t_i_o_n_s_._s_c_h_e_m_a___t_r_a_n_s_l_a_t_e___m_a_p feature such that
│ │ │ │ │ the processing of the SQL statement to receive a specific schema name occurs
│ │ │ │ │ within the execution phase of the statement, rather than at the compile phase.
│ │ │ │ │ This is to support the statement being efficiently cached. Previously, the
│ │ │ │ │ current schema being rendered into the statement for a particular run would be
│ │ │ │ │ considered as part of the cache key itself, meaning that for a run against
│ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html
│ │ │ │┄ Ordering differences only
│ │ │ │ @@ -308,26 +308,26 @@
│ │ │ │
│ │ │ │ Associations¶
│ │ │ │
│ │ │ │ -
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.
│ │ │ │ +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”
│ │ │ │Examples illustrating the asyncio engine feature of SQLAlchemy.
│ │ │ │ @@ -335,19 +335,19 @@ │ │ │ │greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ │ for asynchronous ORM use, including the optional run_sync() method.
│ │ │ │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.
│ │ │ │ +async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object │ │ │ │ for asynchronous ORM use.
│ │ │ │basic.py - Illustrates the asyncio engine / connection interface.
│ │ │ │ -An example of persistence for a directed graph structure. The
│ │ │ │ graph is stored as a collection of edges, each referencing both a
│ │ │ │ @@ -384,37 +384,37 @@
│ │ │ │ subclassing the HasAddresses mixin, which ensures that the
│ │ │ │ parent class is provided with an addresses collection
│ │ │ │ which contains Address objects.
The discriminator_on_association.py and generic_fk.py scripts │ │ │ │ are modernized versions of recipes presented in the 2007 blog post │ │ │ │ Polymorphic Associations with SQLAlchemy.
│ │ │ │Listing of files:
table_per_related.py - Illustrates a generic association which persists association │ │ │ │ +objects within individual tables, each one generated to persist │ │ │ │ +those objects on behalf of a particular parent class.
│ │ │ │ +generic_fk.py - Illustrates a so-called “generic foreign key”, in a similar fashion │ │ │ │ to that of popular frameworks such as Django, ROR, etc. This │ │ │ │ approach bypasses standard referential integrity │ │ │ │ practices, in that the “foreign key” column is not actually │ │ │ │ constrained to refer to any particular table; instead, │ │ │ │ in-application logic is used to determine which table is referenced.
│ │ │ │table_per_association.py - Illustrates a mixin which provides a generic association │ │ │ │ -via a individually generated association tables for each parent class. │ │ │ │ -The associated objects themselves are persisted in a single table │ │ │ │ -shared among all parents.
│ │ │ │ -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.
│ │ │ │ -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.
│ │ │ │ +Large collection example.
│ │ │ │Illustrates the options to use with
│ │ │ │ @@ -503,29 +503,29 @@
│ │ │ │
│ │ │ │ Listing of files: large_resultsets.py - In this series of tests, we are looking at time to load a large number
│ │ │ │ of very small and simple rows.File Listing¶
│ │ │ │
│ │ │ │
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)
│ │ │ │ +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
│ │ │ │__main__.py - Allows the examples/performance package to be run as a script.
│ │ │ │ +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.
│ │ │ │ -bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number │ │ │ │ -of rows in bulk.
│ │ │ │ +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)
│ │ │ │This is the default form of run:
│ │ │ │ @@ -668,22 +668,22 @@ │ │ │ │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.
A Space Invaders game using SQLite as the state machine.
│ │ │ │Originally developed in 2012. Adapted to work in Python 3.
│ │ │ │ @@ -813,47 +813,47 @@ │ │ │ │ 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 │ │ │ │ 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 row to a separate history table.
│ │ │ │Listing of files:
versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning │ │ │ │ -an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ │ -row is inserted with the new data, keeping the old row intact.
│ │ │ │ +versioned_map.py - A variant of the versioned_rows example built around the │ │ │ │ +concept of a “vertical table” structure, like those illustrated in │ │ │ │ +Vertical Attribute Mapping examples.
│ │ │ │versioned_rows.py - Illustrates a method to intercept changes on objects, turning │ │ │ │ an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ │ row is inserted with the new data, keeping the old row intact.
│ │ │ │versioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique of versioned_rows.py,
│ │ │ │ but also emits an UPDATE on the old row to affect a change in timestamp.
│ │ │ │ Also includes a SessionEvents.do_orm_execute() hook to limit queries
│ │ │ │ to only the most recent version.
versioned_map.py - A variant of the versioned_rows example built around the │ │ │ │ -concept of a “vertical table” structure, like those illustrated in │ │ │ │ -Vertical Attribute Mapping examples.
│ │ │ │ +versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning │ │ │ │ +an UPDATE statement on a single row into an INSERT statement, so that a new │ │ │ │ +row is inserted with the new data, keeping the old row intact.
│ │ │ │Listing of files:
dictlike.py - Mapping a vertical table as a dictionary.
│ │ │ │ -dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
│ │ │ │dictlike.py - Mapping a 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:
joined.py - Joined-table (table-per-subclass) inheritance example.
│ │ │ │ +concrete.py - Concrete-table (table-per-class) inheritance example.
│ │ │ │single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │ │concrete.py - Concrete-table (table-per-class) inheritance example.
│ │ │ │ +joined.py - Joined-table (table-per-subclass) inheritance example.
│ │ │ │Examples illustrating modifications to SQLAlchemy’s attribute management │ │ │ │ system.
│ │ │ │Listing of files:
listen_for_events.py - Illustrates how to attach events to all instrumented attributes │ │ │ │ +and listen for change events.
│ │ │ │ +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.
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.
The construction of generic sharding routines is an ambitious approach │ │ │ │ to the issue of organizing instances among multiple databases. For a │ │ │ │ more plain-spoken alternative, the “distinct entity” approach │ │ │ │ is a simple method of assigning objects to different tables (and potentially │ │ │ │ database nodes) in an explicit way - described on the wiki at │ │ │ │ EntityName.
│ │ │ │Listing of files:
separate_databases.py - Illustrates sharding using distinct SQLite databases.
│ │ │ │ -separate_schema_translates.py - Illustrates sharding using a single database with multiple schemas, │ │ │ │ where a different “schema_translates_map” can be used for each shard.
│ │ │ │separate_tables.py - Illustrates sharding using a single SQLite database, that will however │ │ │ │ have multiple tables using a naming convention.
│ │ │ │separate_databases.py - Illustrates sharding using distinct SQLite databases.
│ │ │ │ +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 {} │ │ │ │ │ @@ -105,36 +105,36 @@ │ │ │ │ │ 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. │ │ │ │ │ _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. │ │ │ │ │ +_b_a_s_i_c___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrate a many-to-many relationship between an │ │ │ │ │ +“Order” and a collection of “Item” objects, associating a purchase price with │ │ │ │ │ +each via an association object called “OrderItem” │ │ │ │ │ ******** AAssyynncciioo IInntteeggrraattiioonn_?¶ ******** │ │ │ │ │ Examples illustrating the asyncio engine feature of SQLAlchemy. │ │ │ │ │ Listing of files: │ │ │ │ │ * _g_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_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. │ │ │ │ │ +_b_a_s_i_c_._p_y - Illustrates the asyncio engine / connection interface. │ │ │ │ │ _a_s_y_n_c___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession │ │ │ │ │ object for asynchronous ORM use. │ │ │ │ │ -_b_a_s_i_c_._p_y - Illustrates the asyncio engine / connection interface. │ │ │ │ │ ******** DDiirreecctteedd GGrraapphhss_?¶ ******** │ │ │ │ │ An example of persistence for a directed graph structure. The graph is stored │ │ │ │ │ as a collection of edges, each referencing both a “lower” and an “upper” node │ │ │ │ │ in a table of nodes. Basic persistence and querying for lower- and upper- │ │ │ │ │ neighbors are illustrated: │ │ │ │ │ n2 = Node(2) │ │ │ │ │ n5 = Node(5) │ │ │ │ │ @@ -156,32 +156,31 @@ │ │ │ │ │ Supplier, both subclassing the HasAddresses mixin, which ensures that the │ │ │ │ │ parent class is provided with an addresses collection which contains Address │ │ │ │ │ objects. │ │ │ │ │ The _d_i_s_c_r_i_m_i_n_a_t_o_r___o_n___a_s_s_o_c_i_a_t_i_o_n_._p_y and _g_e_n_e_r_i_c___f_k_._p_y scripts are modernized │ │ │ │ │ versions of recipes presented in the 2007 blog post _P_o_l_y_m_o_r_p_h_i_c_ _A_s_s_o_c_i_a_t_i_o_n_s │ │ │ │ │ _w_i_t_h_ _S_Q_L_A_l_c_h_e_m_y. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _g_e_n_e_r_i_c___f_k_._p_y - Illustrates a so-called “generic foreign key”, in a │ │ │ │ │ - similar fashion to that of popular frameworks such as Django, ROR, etc. │ │ │ │ │ - This approach bypasses standard referential integrity practices, in that │ │ │ │ │ - the “foreign key” column is not actually constrained to refer to any │ │ │ │ │ - particular table; instead, in-application logic is used to determine │ │ │ │ │ - which table is referenced. │ │ │ │ │ -_t_a_b_l_e___p_e_r___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic │ │ │ │ │ -association via a individually generated association tables for each parent │ │ │ │ │ -class. The associated objects themselves are persisted in a single table shared │ │ │ │ │ -among all parents. │ │ │ │ │ -_t_a_b_l_e___p_e_r___r_e_l_a_t_e_d_._p_y - Illustrates a generic association which persists │ │ │ │ │ -association objects within individual tables, each one generated to persist │ │ │ │ │ -those objects on behalf of a particular parent class. │ │ │ │ │ + * _t_a_b_l_e___p_e_r___r_e_l_a_t_e_d_._p_y - Illustrates a generic association which persists │ │ │ │ │ + association objects within individual tables, each one generated to │ │ │ │ │ + persist those objects on behalf of a particular parent class. │ │ │ │ │ +_g_e_n_e_r_i_c___f_k_._p_y - Illustrates a so-called “generic foreign key”, in a similar │ │ │ │ │ +fashion to that of popular frameworks such as Django, ROR, etc. This approach │ │ │ │ │ +bypasses standard referential integrity practices, in that the “foreign key” │ │ │ │ │ +column is not actually constrained to refer to any particular table; instead, │ │ │ │ │ +in-application logic is used to determine which table is referenced. │ │ │ │ │ _d_i_s_c_r_i_m_i_n_a_t_o_r___o_n___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic │ │ │ │ │ association using a single target table and a single association table, │ │ │ │ │ referred to by all parent tables. The association table contains a │ │ │ │ │ “discriminator” column which determines what type of parent object associates │ │ │ │ │ to each particular row in the association table. │ │ │ │ │ +_t_a_b_l_e___p_e_r___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic │ │ │ │ │ +association via a individually generated association tables for each parent │ │ │ │ │ +class. The associated objects themselves are persisted in a single table shared │ │ │ │ │ +among all parents. │ │ │ │ │ ******** LLaarrggee CCoolllleeccttiioonnss_?¶ ******** │ │ │ │ │ Large collection example. │ │ │ │ │ Illustrates the options to use with _r_e_l_a_t_i_o_n_s_h_i_p_(_) when the list of related │ │ │ │ │ objects is very large, including: │ │ │ │ │ * “dynamic” relationships which query slices of data as accessed │ │ │ │ │ * how to use ON DELETE CASCADE in conjunction with passive_deletes=True to │ │ │ │ │ greatly improve the performance of related collection deletion. │ │ │ │ │ @@ -240,26 +239,26 @@ │ │ │ │ │ --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: │ │ │ │ │ * _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. │ │ │ │ │ -_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) │ │ │ │ │ +_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. │ │ │ │ │ _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. │ │ │ │ │ -_____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. │ │ │ │ │ +_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) │ │ │ │ │ ****** 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 │ │ │ │ │ @@ -396,20 +395,20 @@ │ │ │ │ │ total time 2.754592 sec │ │ │ │ │ test_subqueryload : load everything, subquery eager loading. (1000 iterations); │ │ │ │ │ total time 2.977696 sec │ │ │ │ │ ******** RReellaattiioonnsshhiipp JJooiinn CCoonnddiittiioonnss_?¶ ******** │ │ │ │ │ Examples of various _r_e_l_a_t_i_o_n_s_h_i_p_(_) configurations, which make use of the │ │ │ │ │ primaryjoin argument to compose special types of join conditions. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _c_a_s_t_._p_y - Illustrate a _r_e_l_a_t_i_o_n_s_h_i_p_(_) that joins two columns where those │ │ │ │ │ - columns are not of the same type, and a CAST must be used on the SQL side │ │ │ │ │ - in order to match them. │ │ │ │ │ -_t_h_r_e_e_w_a_y_._p_y - Illustrate a “three way join” - where a primary table joins to a │ │ │ │ │ -remote table via an association table, but then the primary table also needs to │ │ │ │ │ -refer to some columns in the remote table directly. │ │ │ │ │ + * _t_h_r_e_e_w_a_y_._p_y - Illustrate a “three way join” - where a primary table joins │ │ │ │ │ + to a remote table via an association table, but then the primary table │ │ │ │ │ + also needs to refer to some columns in the remote table directly. │ │ │ │ │ +_c_a_s_t_._p_y - Illustrate a _r_e_l_a_t_i_o_n_s_h_i_p_(_) that joins two columns where those │ │ │ │ │ +columns are not of the same type, and a CAST must be used on the SQL side in │ │ │ │ │ +order to match them. │ │ │ │ │ ******** SSppaaccee IInnvvaaddeerrss_?¶ ******** │ │ │ │ │ A Space Invaders game using SQLite as the state machine. │ │ │ │ │ Originally developed in 2012. Adapted to work in Python 3. │ │ │ │ │ Runs in a textual console using ASCII art. │ │ │ │ │ [../_images/space_invaders.jpg] │ │ │ │ │ To run: │ │ │ │ │ python -m examples.space_invaders.space_invaders │ │ │ │ │ @@ -512,39 +511,38 @@ │ │ │ │ │ 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: │ │ │ │ │ - * _h_i_s_t_o_r_y___m_e_t_a_._p_y - Versioned mixin class and other utilities. │ │ │ │ │ -_t_e_s_t___v_e_r_s_i_o_n_i_n_g_._p_y - Unit tests illustrating usage of the history_meta.py │ │ │ │ │ -module functions. │ │ │ │ │ + * _t_e_s_t___v_e_r_s_i_o_n_i_n_g_._p_y - Unit tests illustrating usage of the history_meta.py │ │ │ │ │ + module functions. │ │ │ │ │ +_h_i_s_t_o_r_y___m_e_t_a_._p_y - Versioned mixin class and other utilities. │ │ │ │ │ ****** VVeerrssiioonniinngg uussiinngg TTeemmppoorraall RRoowwss_?¶ ****** │ │ │ │ │ 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 _V_e_r_s_i_o_n_i_n_g_ _w_i_t_h_ _a_ _H_i_s_t_o_r_y_ _T_a_b_l_e example which writes a history │ │ │ │ │ row to a separate history table. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _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___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___u_p_d_a_t_e___o_l_d___r_o_w_._p_y - Illustrates the same UPDATE into INSERT technique │ │ │ │ │ of versioned_rows.py, but also emits an UPDATE on the oolldd row to affect a │ │ │ │ │ change in timestamp. Also includes a _S_e_s_s_i_o_n_E_v_e_n_t_s_._d_o___o_r_m___e_x_e_c_u_t_e_(_) hook to │ │ │ │ │ limit queries to only the most recent version. │ │ │ │ │ -_v_e_r_s_i_o_n_e_d___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___w___v_e_r_s_i_o_n_i_d_._p_y - Illustrates a method to intercept changes on │ │ │ │ │ +objects, turning an UPDATE statement on a single row into an INSERT statement, │ │ │ │ │ +so that a new row is inserted with the new data, keeping the old row intact. │ │ │ │ │ ******** VVeerrttiiccaall AAttttrriibbuuttee MMaappppiinngg_?¶ ******** │ │ │ │ │ Illustrates “vertical table” mappings. │ │ │ │ │ A “vertical table” refers to a technique where individual attributes of an │ │ │ │ │ object are stored as distinct rows in a table. The “vertical table” technique │ │ │ │ │ is used to persist objects which can have a varied set of attributes, at the │ │ │ │ │ expense of simple query control and brevity. It is commonly found in content/ │ │ │ │ │ document management systems in order to represent user-created structures │ │ │ │ │ @@ -563,36 +561,35 @@ │ │ │ │ │ │ │ │ │ │ q = (session.query(Animal). │ │ │ │ │ filter(Animal.facts.any( │ │ │ │ │ and_(AnimalFact.key == u'weasel-like', │ │ │ │ │ AnimalFact.value == True)))) │ │ │ │ │ print('weasel-like animals', q.all()) │ │ │ │ │ Listing of files: │ │ │ │ │ - * _d_i_c_t_l_i_k_e_._p_y - Mapping a vertical table as a dictionary. │ │ │ │ │ -_d_i_c_t_l_i_k_e_-_p_o_l_y_m_o_r_p_h_i_c_._p_y - Mapping a polymorphic-valued vertical table as a │ │ │ │ │ -dictionary. │ │ │ │ │ + * _d_i_c_t_l_i_k_e_-_p_o_l_y_m_o_r_p_h_i_c_._p_y - Mapping a polymorphic-valued vertical table as │ │ │ │ │ + a dictionary. │ │ │ │ │ +_d_i_c_t_l_i_k_e_._p_y - Mapping a vertical table as a dictionary. │ │ │ │ │ ********** 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: │ │ │ │ │ - * _j_o_i_n_e_d_._p_y - Joined-table (table-per-subclass) inheritance example. │ │ │ │ │ + * _c_o_n_c_r_e_t_e_._p_y - Concrete-table (table-per-class) inheritance example. │ │ │ │ │ _s_i_n_g_l_e_._p_y - Single-table (table-per-hierarchy) inheritance example. │ │ │ │ │ -_c_o_n_c_r_e_t_e_._p_y - Concrete-table (table-per-class) inheritance example. │ │ │ │ │ +_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: │ │ │ │ │ - * _a_c_t_i_v_e___c_o_l_u_m_n___d_e_f_a_u_l_t_s_._p_y - Illustrates use of the │ │ │ │ │ - _A_t_t_r_i_b_u_t_e_E_v_e_n_t_s_._i_n_i_t___s_c_a_l_a_r_(_) event, in conjunction with Core column │ │ │ │ │ - defaults to provide ORM objects that automatically produce the default │ │ │ │ │ - value when an un-set attribute is accessed. │ │ │ │ │ -_l_i_s_t_e_n___f_o_r___e_v_e_n_t_s_._p_y - Illustrates how to attach events to all instrumented │ │ │ │ │ -attributes and listen for change events. │ │ │ │ │ + * _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 │ │ │ │ │ @@ -615,35 +612,34 @@ │ │ │ │ │ attempt to determine a single shard being requested. │ │ │ │ │ The construction of generic sharding routines is an ambitious approach to the │ │ │ │ │ issue of organizing instances among multiple databases. For a more plain-spoken │ │ │ │ │ alternative, the “distinct entity” approach is a simple method of assigning │ │ │ │ │ objects to different tables (and potentially database nodes) in an explicit way │ │ │ │ │ - described on the wiki at _E_n_t_i_t_y_N_a_m_e. │ │ │ │ │ Listing of files: │ │ │ │ │ - * _s_e_p_a_r_a_t_e___d_a_t_a_b_a_s_e_s_._p_y - Illustrates sharding using distinct SQLite │ │ │ │ │ - databases. │ │ │ │ │ -_s_e_p_a_r_a_t_e___s_c_h_e_m_a___t_r_a_n_s_l_a_t_e_s_._p_y - Illustrates sharding using a single database │ │ │ │ │ -with multiple schemas, where a different “schema_translates_map” can be used │ │ │ │ │ -for each shard. │ │ │ │ │ + * _s_e_p_a_r_a_t_e___s_c_h_e_m_a___t_r_a_n_s_l_a_t_e_s_._p_y - Illustrates sharding using a single │ │ │ │ │ + database with multiple schemas, where a different “schema_translates_map” │ │ │ │ │ + can be used for each shard. │ │ │ │ │ _s_e_p_a_r_a_t_e___t_a_b_l_e_s_._p_y - Illustrates sharding using a single SQLite database, that │ │ │ │ │ will however have multiple tables using a naming convention. │ │ │ │ │ +_s_e_p_a_r_a_t_e___d_a_t_a_b_a_s_e_s_._p_y - Illustrates sharding using distinct SQLite databases. │ │ │ │ │ ********** 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 │ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/searchindex.js │ │ │ │ ├── js-beautify {} │ │ │ │ │ @@ -8521,20 +8521,20 @@ │ │ │ │ │ "3414": [13, 25], │ │ │ │ │ "alchemy2": 13, │ │ │ │ │ "4644": 13, │ │ │ │ │ "5649": 13, │ │ │ │ │ "get_sequence_nam": [13, 48, 52], │ │ │ │ │ "2056": 13, │ │ │ │ │ "4755": 13, │ │ │ │ │ - "4524": 13, │ │ │ │ │ "upfront": 13, │ │ │ │ │ "returns_unicode_str": [13, 48], │ │ │ │ │ "returns_condit": [13, 59], │ │ │ │ │ "returns_byt": [13, 59], │ │ │ │ │ "5315": 13, │ │ │ │ │ + "4524": 13, │ │ │ │ │ "hundr": [13, 21, 24, 25, 31, 76, 136, 137, 155], │ │ │ │ │ "4645": [13, 25], │ │ │ │ │ "4808": [13, 25], │ │ │ │ │ "5004": [13, 25], │ │ │ │ │ "har": [13, 25], │ │ │ │ │ "4712": 13, │ │ │ │ │ "5526": [13, 25], │ │ │ │ │ @@ -12459,29 +12459,29 @@ │ │ │ │ │ "receive_class_uninstru": 97, │ │ │ │ │ "rootnod": 98, │ │ │ │ │ "node1": 98, │ │ │ │ │ "node3": 98, │ │ │ │ │ "dump_tre": 98, │ │ │ │ │ "adjacency_list": 98, │ │ │ │ │ "basic_associ": 98, │ │ │ │ │ - "purchas": 98, │ │ │ │ │ "orderitem": 98, │ │ │ │ │ + "purchas": 98, │ │ │ │ │ "gather_orm_stat": 98, │ │ │ │ │ "async_orm": 98, │ │ │ │ │ "neighbor": 98, │ │ │ │ │ "n5": 98, │ │ │ │ │ "add_neighbor": 98, │ │ │ │ │ "higher_neighbor": 98, │ │ │ │ │ "directed_graph": 98, │ │ │ │ │ "supplier": 98, │ │ │ │ │ "hasaddress": 98, │ │ │ │ │ "generic_fk": 98, │ │ │ │ │ + "table_per_rel": 98, │ │ │ │ │ "ror": 98, │ │ │ │ │ "table_per_associ": 98, │ │ │ │ │ - "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, │ │ │ │ │ "test_cor": 98, │ │ │ │ │ @@ -12536,34 +12536,34 @@ │ │ │ │ │ "sc1": 98, │ │ │ │ │ "sc1modifi": 98, │ │ │ │ │ "someclasshistori": 98, │ │ │ │ │ "__history_mapper__": 98, │ │ │ │ │ "_history_mapp": 98, │ │ │ │ │ "somehistoryclass": 98, │ │ │ │ │ "use_mapper_vers": 98, │ │ │ │ │ - "versioned_rows_w_versionid": 98, │ │ │ │ │ - "versioned_update_old_row": 98, │ │ │ │ │ "versioned_map": 98, │ │ │ │ │ + "versioned_update_old_row": 98, │ │ │ │ │ + "versioned_rows_w_versionid": 98, │ │ │ │ │ "breviti": 98, │ │ │ │ │ "shrew": 98, │ │ │ │ │ "anim": 98, │ │ │ │ │ "cute": 98, │ │ │ │ │ "weasel": 98, │ │ │ │ │ "poison": 98, │ │ │ │ │ "animalfact": 98, │ │ │ │ │ "custom_manag": 98, │ │ │ │ │ "weather": 98, │ │ │ │ │ "contin": 98, │ │ │ │ │ "spoken": 98, │ │ │ │ │ - "separate_databas": 98, │ │ │ │ │ "separate_schema_transl": 98, │ │ │ │ │ "schema_translates_map": 98, │ │ │ │ │ "separate_t": 98, │ │ │ │ │ - "filter_publ": 98, │ │ │ │ │ + "separate_databas": 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], │ │ ├── xz --list │ │ │ @@ -1,14 +1,14 @@ │ │ │ Streams: 1 │ │ │ Blocks: 2 │ │ │ - Compressed size: 3619.4 KiB (3706316 B) │ │ │ + Compressed size: 3619.7 KiB (3706560 B) │ │ │ Uncompressed size: 36.3 MiB (38051840 B) │ │ │ Ratio: 0.097 │ │ │ Check: CRC64 │ │ │ Stream Padding: 0 B │ │ │ Streams: │ │ │ Stream Blocks CompOffset UncompOffset CompSize UncompSize Ratio Check Padding │ │ │ - 1 2 0 0 3706316 38051840 0.097 CRC64 0 │ │ │ + 1 2 0 0 3706560 38051840 0.097 CRC64 0 │ │ │ Blocks: │ │ │ Stream Block CompOffset UncompOffset TotalSize UncompSize Ratio Check │ │ │ - 1 1 12 0 2076452 25165824 0.083 CRC64 │ │ │ - 1 2 2076464 25165824 1629820 12886016 0.126 CRC64 │ │ │ + 1 1 12 0 2076520 25165824 0.083 CRC64 │ │ │ + 1 2 2076532 25165824 1629996 12886016 0.126 CRC64