--- /srv/reproducible-results/rbuild-debian/r-b-build.EavwGKyb/b1/sqlalchemy_1.4.50+ds1-1_amd64.changes
+++ /srv/reproducible-results/rbuild-debian/r-b-build.EavwGKyb/b2/sqlalchemy_1.4.50+ds1-1_amd64.changes
├── Files
│ @@ -1,5 +1,5 @@
│
│ - ed964aff8e77b943989a5917e2858f73 3720076 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb
│ + 3f67245a2ffb1f76d0a6e36142d10a7b 3720016 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb
│ 397dc71818c832a10795aefe2fa8bcbb 70296 debug optional python3-sqlalchemy-ext-dbgsym_1.4.50+ds1-1_amd64.deb
│ 3b41bed8e1bb07c1668ba0caa003f1cc 20936 python optional python3-sqlalchemy-ext_1.4.50+ds1-1_amd64.deb
│ 7b9b7746123a45060be2c12bd6e80ed4 1009400 python optional python3-sqlalchemy_1.4.50+ds1-1_all.deb
├── python-sqlalchemy-doc_1.4.50+ds1-1_all.deb
│ ├── file list
│ │ @@ -1,3 +1,3 @@
│ │ -rw-r--r-- 0 0 0 4 2024-01-05 13:47:47.000000 debian-binary
│ │ -rw-r--r-- 0 0 0 13376 2024-01-05 13:47:47.000000 control.tar.xz
│ │ --rw-r--r-- 0 0 0 3706508 2024-01-05 13:47:47.000000 data.tar.xz
│ │ +-rw-r--r-- 0 0 0 3706448 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/orm/examples.html
│ │ │ │┄ Ordering differences only
│ │ │ │ @@ -308,46 +308,46 @@
│ │ │ │
│ │ │ │
│ │ │ │ Associations
│ │ │ │ Examples illustrating the usage of the “association object” pattern,
│ │ │ │ where an intermediary class mediates the relationship between two
│ │ │ │ classes that are associated in a many-to-many pattern.
│ │ │ │ Listing of files:
│ │ │ │ dict_of_sets_with_default.py - An advanced association proxy example which
│ │ │ │ illustrates nesting of association proxies to produce multi-level Python
│ │ │ │ collections, in this case a dictionary with string keys and sets of integers
│ │ │ │ as values, which conceal the underlying mapped classes.
│ │ │ │
│ │ │ │ proxied_association.py - Same example as basic_association, adding in
│ │ │ │ usage of sqlalchemy.ext.associationproxy
to make explicit references
│ │ │ │ to OrderItem
optional.
│ │ │ │
│ │ │ │ +basic_association.py - Illustrate a many-to-many relationship between an
│ │ │ │ +“Order” and a collection of “Item” objects, associating a purchase price
│ │ │ │ +with each via an association object called “OrderItem”
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Asyncio Integration
│ │ │ │ Examples illustrating the asyncio engine feature of SQLAlchemy.
│ │ │ │ Listing of files:
│ │ │ │ -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
.
│ │ │ │
│ │ │ │ -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.
│ │ │ │
│ │ │ │ +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
│ │ │ │ @@ -388,32 +388,32 @@
│ │ │ │ are modernized versions of recipes presented in the 2007 blog post
│ │ │ │ Polymorphic Associations with SQLAlchemy.
│ │ │ │ Listing of files:
│ │ │ │ table_per_related.py - Illustrates a generic association which persists association
│ │ │ │ objects within individual tables, each one generated to persist
│ │ │ │ those objects on behalf of a particular parent class.
│ │ │ │
│ │ │ │ -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.
│ │ │ │
│ │ │ │ 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.
│ │ │ │
│ │ │ │ -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.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Large Collections
│ │ │ │ Large collection example.
│ │ │ │ @@ -503,30 +503,30 @@
│ │ │ │
│ │ │ │
│ │ │ │ File Listing
│ │ │ │ Listing of files:
│ │ │ │ bulk_updates.py - This series of tests will illustrate different ways to UPDATE a large number
│ │ │ │ of rows in bulk (under construction! there’s just one test at the moment)
│ │ │ │
│ │ │ │ -large_resultsets.py - In this series of tests, we are looking at time to load a large number
│ │ │ │ -of very small and simple rows.
│ │ │ │ -
│ │ │ │ single_inserts.py - In this series of tests, we’re looking at a method that inserts a row
│ │ │ │ within a distinct transaction, and afterwards returns to essentially a
│ │ │ │ “closed” state. This would be analogous to an API call that starts up
│ │ │ │ a database connection, inserts the row, commits and closes.
│ │ │ │
│ │ │ │ +bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number
│ │ │ │ +of rows in bulk.
│ │ │ │ +
│ │ │ │ +large_resultsets.py - In this series of tests, we are looking at time to load a large number
│ │ │ │ +of very small and simple rows.
│ │ │ │ +
│ │ │ │ __main__.py - Allows the examples/performance package to be run as a script.
│ │ │ │
│ │ │ │ short_selects.py - This series of tests illustrates different ways to SELECT a single
│ │ │ │ record by primary key
│ │ │ │
│ │ │ │ -bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number
│ │ │ │ -of rows in bulk.
│ │ │ │ -
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Running all tests with time
│ │ │ │ This is the default form of run:
│ │ │ │ $ python -m examples.performance single_inserts
│ │ │ │ @@ -668,22 +668,22 @@
│ │ │ │
│ │ │ │
│ │ │ │ Relationship Join Conditions
│ │ │ │ Examples of various relationship()
configurations,
│ │ │ │ which make use of the primaryjoin
argument to compose special types
│ │ │ │ of join conditions.
│ │ │ │ Listing of files:
│ │ │ │ -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.
│ │ │ │ @@ -838,23 +838,23 @@
│ │ │ │ concept of a “vertical table” structure, like those illustrated in
│ │ │ │ Vertical Attribute Mapping examples.
│ │ │ │
│ │ │ │ versioned_rows.py - Illustrates a method to intercept changes on objects, turning
│ │ │ │ an UPDATE statement on a single row into an INSERT statement, so that a new
│ │ │ │ row is inserted with the new data, keeping the old row intact.
│ │ │ │
│ │ │ │ +versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning
│ │ │ │ +an UPDATE statement on a single row into an INSERT statement, so that a new
│ │ │ │ +row is inserted with the new data, keeping the old row intact.
│ │ │ │ +
│ │ │ │ versioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique of versioned_rows.py
,
│ │ │ │ but also emits an UPDATE on the old row to affect a change in timestamp.
│ │ │ │ Also includes a SessionEvents.do_orm_execute()
hook to limit queries
│ │ │ │ to only the most recent version.
│ │ │ │
│ │ │ │ -versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning
│ │ │ │ -an UPDATE statement on a single row into an INSERT statement, so that a new
│ │ │ │ -row is inserted with the new data, keeping the old row intact.
│ │ │ │ -
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Vertical Attribute Mapping
│ │ │ │ Illustrates “vertical table” mappings.
│ │ │ │ @@ -879,57 +879,57 @@
│ │ │ │ q = (session.query(Animal).
│ │ │ │ filter(Animal.facts.any(
│ │ │ │ and_(AnimalFact.key == u'weasel-like',
│ │ │ │ AnimalFact.value == True))))
│ │ │ │ print('weasel-like animals', q.all())
│ │ │ │
│ │ │ │ Listing of files:
│ │ │ │ -dictlike.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.
│ │ │ │ +
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Inheritance Mapping Recipes
│ │ │ │
│ │ │ │ Basic Inheritance Mappings
│ │ │ │ Working examples of single-table, joined-table, and concrete-table
│ │ │ │ inheritance as described in Mapping Class Inheritance Hierarchies.
│ │ │ │ Listing of files:
│ │ │ │ +single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │ │ +
│ │ │ │ concrete.py - Concrete-table (table-per-class) inheritance example.
│ │ │ │
│ │ │ │ joined.py - Joined-table (table-per-subclass) inheritance example.
│ │ │ │
│ │ │ │ -single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │ │ -
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Special APIs
│ │ │ │
│ │ │ │ Attribute Instrumentation
│ │ │ │ Examples illustrating modifications to SQLAlchemy’s attribute management
│ │ │ │ system.
│ │ │ │ Listing of files:
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Horizontal Sharding
│ │ │ │ A basic example of using the SQLAlchemy Sharding API.
│ │ │ │ Sharding refers to horizontally scaling data across multiple
│ │ │ │ @@ -958,21 +958,21 @@
│ │ │ │
The construction of generic sharding routines is an ambitious approach
│ │ │ │ to the issue of organizing instances among multiple databases. For a
│ │ │ │ more plain-spoken alternative, the “distinct entity” approach
│ │ │ │ is a simple method of assigning objects to different tables (and potentially
│ │ │ │ database nodes) in an explicit way - described on the wiki at
│ │ │ │ EntityName.
│ │ │ │ Listing of files:
│ │ │ │ -separate_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.
│ │ │ │ +separate_databases.py - Illustrates sharding using distinct SQLite databases.
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ Extending the ORM
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -105,35 +105,35 @@
│ │ │ │ │ Listing of files:
│ │ │ │ │ * _a_d_j_a_c_e_n_c_y___l_i_s_t_._p_y
│ │ │ │ │ ******** AAssssoocciiaattiioonnss_?¶ ********
│ │ │ │ │ Examples illustrating the usage of the “association object” pattern, where an
│ │ │ │ │ intermediary class mediates the relationship between two classes that are
│ │ │ │ │ associated in a many-to-many pattern.
│ │ │ │ │ Listing of files:
│ │ │ │ │ - * _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.
│ │ │ │ │ + * _d_i_c_t___o_f___s_e_t_s___w_i_t_h___d_e_f_a_u_l_t_._p_y - An advanced association proxy example
│ │ │ │ │ + which illustrates nesting of association proxies to produce multi-level
│ │ │ │ │ + Python collections, in this case a dictionary with string keys and sets
│ │ │ │ │ + of integers as values, which conceal the underlying mapped classes.
│ │ │ │ │ _p_r_o_x_i_e_d___a_s_s_o_c_i_a_t_i_o_n_._p_y - Same example as basic_association, adding in usage of
│ │ │ │ │ _s_q_l_a_l_c_h_e_m_y_._e_x_t_._a_s_s_o_c_i_a_t_i_o_n_p_r_o_x_y to make explicit references to OrderItem
│ │ │ │ │ optional.
│ │ │ │ │ +_b_a_s_i_c___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrate a many-to-many relationship between an
│ │ │ │ │ +“Order” and a collection of “Item” objects, associating a purchase price with
│ │ │ │ │ +each via an association object called “OrderItem”
│ │ │ │ │ ******** AAssyynncciioo IInntteeggrraattiioonn_?¶ ********
│ │ │ │ │ Examples illustrating the asyncio engine feature of SQLAlchemy.
│ │ │ │ │ Listing of files:
│ │ │ │ │ - * _a_s_y_n_c___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession
│ │ │ │ │ - object for asynchronous ORM use.
│ │ │ │ │ -_g_a_t_h_e_r___o_r_m___s_t_a_t_e_m_e_n_t_s_._p_y - Illustrates how to run many statements concurrently
│ │ │ │ │ -using asyncio.gather() along many asyncio database connections, merging ORM
│ │ │ │ │ -results into a single AsyncSession.
│ │ │ │ │ + * _g_a_t_h_e_r___o_r_m___s_t_a_t_e_m_e_n_t_s_._p_y - Illustrates how to run many statements
│ │ │ │ │ + concurrently using asyncio.gather() along many asyncio database
│ │ │ │ │ + connections, merging ORM results into a single AsyncSession.
│ │ │ │ │ +_a_s_y_n_c___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession
│ │ │ │ │ +object for asynchronous ORM use.
│ │ │ │ │ +_b_a_s_i_c_._p_y - Illustrates the asyncio engine / connection interface.
│ │ │ │ │ _g_r_e_e_n_l_e_t___o_r_m_._p_y - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession
│ │ │ │ │ object for asynchronous ORM use, including the optional run_sync() method.
│ │ │ │ │ -_b_a_s_i_c_._p_y - Illustrates the asyncio engine / connection interface.
│ │ │ │ │ ******** DDiirreecctteedd GGrraapphhss_?¶ ********
│ │ │ │ │ An example of persistence for a directed graph structure. The graph is stored
│ │ │ │ │ as a collection of edges, each referencing both a “lower” and an “upper” node
│ │ │ │ │ in a table of nodes. Basic persistence and querying for lower- and upper-
│ │ │ │ │ neighbors are illustrated:
│ │ │ │ │ n2 = Node(2)
│ │ │ │ │ n5 = Node(5)
│ │ │ │ │ @@ -158,28 +158,28 @@
│ │ │ │ │ The _d_i_s_c_r_i_m_i_n_a_t_o_r___o_n___a_s_s_o_c_i_a_t_i_o_n_._p_y and _g_e_n_e_r_i_c___f_k_._p_y scripts are modernized
│ │ │ │ │ versions of recipes presented in the 2007 blog post _P_o_l_y_m_o_r_p_h_i_c_ _A_s_s_o_c_i_a_t_i_o_n_s
│ │ │ │ │ _w_i_t_h_ _S_Q_L_A_l_c_h_e_m_y.
│ │ │ │ │ Listing of files:
│ │ │ │ │ * _t_a_b_l_e___p_e_r___r_e_l_a_t_e_d_._p_y - Illustrates a generic association which persists
│ │ │ │ │ association objects within individual tables, each one generated to
│ │ │ │ │ persist those objects on behalf of a particular parent class.
│ │ │ │ │ -_t_a_b_l_e___p_e_r___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic
│ │ │ │ │ -association via a individually generated association tables for each parent
│ │ │ │ │ -class. The associated objects themselves are persisted in a single table shared
│ │ │ │ │ -among all parents.
│ │ │ │ │ -_d_i_s_c_r_i_m_i_n_a_t_o_r___o_n___a_s_s_o_c_i_a_t_i_o_n_._p_y - Illustrates a mixin which provides a generic
│ │ │ │ │ -association using a single target table and a single association table,
│ │ │ │ │ -referred to by all parent tables. The association table contains a
│ │ │ │ │ -“discriminator” column which determines what type of parent object associates
│ │ │ │ │ -to each particular row in the association table.
│ │ │ │ │ _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.
│ │ │ │ │ @@ -239,25 +239,25 @@
│ │ │ │ │ See also
│ │ │ │ │ _H_o_w_ _c_a_n_ _I_ _p_r_o_f_i_l_e_ _a_ _S_Q_L_A_l_c_h_e_m_y_ _p_o_w_e_r_e_d_ _a_p_p_l_i_c_a_t_i_o_n_?
│ │ │ │ │ ****** FFiillee LLiissttiinngg_?¶ ******
│ │ │ │ │ Listing of files:
│ │ │ │ │ * _b_u_l_k___u_p_d_a_t_e_s_._p_y - This series of tests will illustrate different ways to
│ │ │ │ │ UPDATE a large number of rows in bulk (under construction! there’s just
│ │ │ │ │ one test at the moment)
│ │ │ │ │ -_l_a_r_g_e___r_e_s_u_l_t_s_e_t_s_._p_y - In this series of tests, we are looking at time to load a
│ │ │ │ │ -large number of very small and simple rows.
│ │ │ │ │ _s_i_n_g_l_e___i_n_s_e_r_t_s_._p_y - In this series of tests, we’re looking at a method that
│ │ │ │ │ inserts a row within a distinct transaction, and afterwards returns to
│ │ │ │ │ essentially a “closed” state. This would be analogous to an API call that
│ │ │ │ │ starts up a database connection, inserts the row, commits and closes.
│ │ │ │ │ +_b_u_l_k___i_n_s_e_r_t_s_._p_y - This series of tests illustrates different ways to INSERT a
│ │ │ │ │ +large number of rows in bulk.
│ │ │ │ │ +_l_a_r_g_e___r_e_s_u_l_t_s_e_t_s_._p_y - In this series of tests, we are looking at time to load a
│ │ │ │ │ +large number of very small and simple rows.
│ │ │ │ │ _____m_a_i_n_____._p_y - Allows the examples/performance package to be run as a script.
│ │ │ │ │ _s_h_o_r_t___s_e_l_e_c_t_s_._p_y - This series of tests illustrates different ways to SELECT a
│ │ │ │ │ single record by primary key
│ │ │ │ │ -_b_u_l_k___i_n_s_e_r_t_s_._p_y - This series of tests illustrates different ways to INSERT a
│ │ │ │ │ -large number of rows in bulk.
│ │ │ │ │ ****** RRuunnnniinngg aallll tteessttss wwiitthh ttiimmee_?¶ ******
│ │ │ │ │ This is the default form of run:
│ │ │ │ │ $ python -m examples.performance single_inserts
│ │ │ │ │ Tests to run: test_orm_commit, test_bulk_save,
│ │ │ │ │ test_bulk_insert_dictionaries, test_core,
│ │ │ │ │ test_core_query_caching, test_dbapi_raw_w_connect,
│ │ │ │ │ test_dbapi_raw_w_pool
│ │ │ │ │ @@ -394,20 +394,20 @@
│ │ │ │ │ total time 2.754592 sec
│ │ │ │ │ test_subqueryload : load everything, subquery eager loading. (1000 iterations);
│ │ │ │ │ total time 2.977696 sec
│ │ │ │ │ ******** RReellaattiioonnsshhiipp JJooiinn CCoonnddiittiioonnss_?¶ ********
│ │ │ │ │ Examples of various _r_e_l_a_t_i_o_n_s_h_i_p_(_) configurations, which make use of the
│ │ │ │ │ primaryjoin argument to compose special types of join conditions.
│ │ │ │ │ Listing of files:
│ │ │ │ │ - * _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
│ │ │ │ │ @@ -527,21 +527,21 @@
│ │ │ │ │ Listing of files:
│ │ │ │ │ * _v_e_r_s_i_o_n_e_d___m_a_p_._p_y - A variant of the versioned_rows example built around
│ │ │ │ │ the concept of a “vertical table” structure, like those illustrated in
│ │ │ │ │ _V_e_r_t_i_c_a_l_ _A_t_t_r_i_b_u_t_e_ _M_a_p_p_i_n_g examples.
│ │ │ │ │ _v_e_r_s_i_o_n_e_d___r_o_w_s_._p_y - Illustrates a method to intercept changes on objects,
│ │ │ │ │ turning an UPDATE statement on a single row into an INSERT statement, so that a
│ │ │ │ │ new row is inserted with the new data, keeping the old row intact.
│ │ │ │ │ +_v_e_r_s_i_o_n_e_d___r_o_w_s___w___v_e_r_s_i_o_n_i_d_._p_y - Illustrates a method to intercept changes on
│ │ │ │ │ +objects, turning an UPDATE statement on a single row into an INSERT statement,
│ │ │ │ │ +so that a new row is inserted with the new data, keeping the old row intact.
│ │ │ │ │ _v_e_r_s_i_o_n_e_d___u_p_d_a_t_e___o_l_d___r_o_w_._p_y - Illustrates the same UPDATE into INSERT technique
│ │ │ │ │ of versioned_rows.py, but also emits an UPDATE on the oolldd row to affect a
│ │ │ │ │ change in timestamp. Also includes a _S_e_s_s_i_o_n_E_v_e_n_t_s_._d_o___o_r_m___e_x_e_c_u_t_e_(_) hook to
│ │ │ │ │ limit queries to only the most recent version.
│ │ │ │ │ -_v_e_r_s_i_o_n_e_d___r_o_w_s___w___v_e_r_s_i_o_n_i_d_._p_y - Illustrates a method to intercept changes on
│ │ │ │ │ -objects, turning an UPDATE statement on a single row into an INSERT statement,
│ │ │ │ │ -so that a new row is inserted with the new data, keeping the old row intact.
│ │ │ │ │ ******** VVeerrttiiccaall AAttttrriibbuuttee MMaappppiinngg_?¶ ********
│ │ │ │ │ Illustrates “vertical table” mappings.
│ │ │ │ │ A “vertical table” refers to a technique where individual attributes of an
│ │ │ │ │ object are stored as distinct rows in a table. The “vertical table” technique
│ │ │ │ │ is used to persist objects which can have a varied set of attributes, at the
│ │ │ │ │ expense of simple query control and brevity. It is commonly found in content/
│ │ │ │ │ document management systems in order to represent user-created structures
│ │ │ │ │ @@ -560,37 +560,38 @@
│ │ │ │ │
│ │ │ │ │ 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:
│ │ │ │ │ - * _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.
│ │ │ │ │ -_s_i_n_g_l_e_._p_y - Single-table (table-per-hierarchy) inheritance example.
│ │ │ │ │ ********** SSppeecciiaall AAPPIIss_?¶ **********
│ │ │ │ │ ******** AAttttrriibbuuttee IInnssttrruummeennttaattiioonn_?¶ ********
│ │ │ │ │ Examples illustrating modifications to SQLAlchemy’s attribute management
│ │ │ │ │ system.
│ │ │ │ │ Listing of files:
│ │ │ │ │ - * _c_u_s_t_o_m___m_a_n_a_g_e_m_e_n_t_._p_y - Illustrates customized class instrumentation,
│ │ │ │ │ - using the _s_q_l_a_l_c_h_e_m_y_._e_x_t_._i_n_s_t_r_u_m_e_n_t_a_t_i_o_n extension package.
│ │ │ │ │ -_a_c_t_i_v_e___c_o_l_u_m_n___d_e_f_a_u_l_t_s_._p_y - Illustrates use of the _A_t_t_r_i_b_u_t_e_E_v_e_n_t_s_._i_n_i_t___s_c_a_l_a_r
│ │ │ │ │ -_(_) event, in conjunction with Core column defaults to provide ORM objects that
│ │ │ │ │ -automatically produce the default value when an un-set attribute is accessed.
│ │ │ │ │ + * _a_c_t_i_v_e___c_o_l_u_m_n___d_e_f_a_u_l_t_s_._p_y - Illustrates use of the
│ │ │ │ │ + _A_t_t_r_i_b_u_t_e_E_v_e_n_t_s_._i_n_i_t___s_c_a_l_a_r_(_) event, in conjunction with Core column
│ │ │ │ │ + defaults to provide ORM objects that automatically produce the default
│ │ │ │ │ + value when an un-set attribute is accessed.
│ │ │ │ │ _l_i_s_t_e_n___f_o_r___e_v_e_n_t_s_._p_y - Illustrates how to attach events to all instrumented
│ │ │ │ │ attributes and listen for change events.
│ │ │ │ │ +_c_u_s_t_o_m___m_a_n_a_g_e_m_e_n_t_._p_y - Illustrates customized class instrumentation, using the
│ │ │ │ │ +_s_q_l_a_l_c_h_e_m_y_._e_x_t_._i_n_s_t_r_u_m_e_n_t_a_t_i_o_n extension package.
│ │ │ │ │ ******** HHoorriizzoonnttaall SShhaarrddiinngg_?¶ ********
│ │ │ │ │ A basic example of using the SQLAlchemy Sharding API. Sharding refers to
│ │ │ │ │ horizontally scaling data across multiple databases.
│ │ │ │ │ The basic components of a “sharded” mapping are:
│ │ │ │ │ * multiple _E_n_g_i_n_e instances, each assigned a “shard id”. These _E_n_g_i_n_e
│ │ │ │ │ instances may refer to different databases, or different schemas /
│ │ │ │ │ accounts within the same database, or they can even be differentiated
│ │ │ │ │ @@ -611,21 +612,20 @@
│ │ │ │ │ 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___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___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.
│ │ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/searchindex.js
│ │ │ │ ├── js-beautify {}
│ │ │ │ │ @@ -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,
│ │ │ │ │ - "async_orm": 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,
│ │ │ │ │ - "table_per_associ": 98,
│ │ │ │ │ "ror": 98,
│ │ │ │ │ + "table_per_associ": 98,
│ │ │ │ │ "materialized_path": 98,
│ │ │ │ │ "nested_set": 98,
│ │ │ │ │ "single_insert": 98,
│ │ │ │ │ "bulk_upd": 98,
│ │ │ │ │ "test_orm_commit": 98,
│ │ │ │ │ "test_bulk_insert_dictionari": 98,
│ │ │ │ │ "test_cor": 98,
│ │ │ │ │ @@ -12537,31 +12537,31 @@
│ │ │ │ │ "sc1modifi": 98,
│ │ │ │ │ "someclasshistori": 98,
│ │ │ │ │ "__history_mapper__": 98,
│ │ │ │ │ "_history_mapp": 98,
│ │ │ │ │ "somehistoryclass": 98,
│ │ │ │ │ "use_mapper_vers": 98,
│ │ │ │ │ "versioned_map": 98,
│ │ │ │ │ - "versioned_update_old_row": 98,
│ │ │ │ │ "versioned_rows_w_versionid": 98,
│ │ │ │ │ + "versioned_update_old_row": 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_t": 98,
│ │ │ │ │ "separate_schema_transl": 98,
│ │ │ │ │ "schema_translates_map": 98,
│ │ │ │ │ - "separate_t": 98,
│ │ │ │ │ + "separate_databas": 98,
│ │ │ │ │ "temporal_rang": 98,
│ │ │ │ │ "filter_publ": 98,
│ │ │ │ │ "demo": 98,
│ │ │ │ │ "datafil": 98,
│ │ │ │ │ "helloworld": 98,
│ │ │ │ │ "local_session_cach": 98,
│ │ │ │ │ "datamodel": 98,
│ │ ├── xz --list
│ │ │ @@ -1,14 +1,14 @@
│ │ │ Streams: 1
│ │ │ Blocks: 2
│ │ │ - Compressed size: 3619.6 KiB (3706508 B)
│ │ │ + Compressed size: 3619.6 KiB (3706448 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 3706508 38051840 0.097 CRC64 0
│ │ │ + 1 2 0 0 3706448 38051840 0.097 CRC64 0
│ │ │ Blocks:
│ │ │ Stream Block CompOffset UncompOffset TotalSize UncompSize Ratio Check
│ │ │ - 1 1 12 0 2076544 25165824 0.083 CRC64
│ │ │ - 1 2 2076556 25165824 1629920 12886016 0.126 CRC64
│ │ │ + 1 1 12 0 2076516 25165824 0.083 CRC64
│ │ │ + 1 2 2076528 25165824 1629888 12886016 0.126 CRC64