--- /srv/reproducible-results/rbuild-debian/r-b-build.ub1oUsXD/b1/sqlalchemy_1.3.22+ds1-1_i386.changes +++ /srv/reproducible-results/rbuild-debian/r-b-build.ub1oUsXD/b2/sqlalchemy_1.3.22+ds1-1_i386.changes ├── Files │ @@ -1,5 +1,5 @@ │ │ - 8aa9964097deb3d79961600394dcd2be 2567568 doc optional python-sqlalchemy-doc_1.3.22+ds1-1_all.deb │ + 2bbf707c43a2a305a3aa195894d2b24c 2567540 doc optional python-sqlalchemy-doc_1.3.22+ds1-1_all.deb │ b2cc03740fda8c79971ac65a2a30fcb6 33352 debug optional python3-sqlalchemy-ext-dbgsym_1.3.22+ds1-1_i386.deb │ 9b86b9d86d09f09c76edbe04efabca40 20196 python optional python3-sqlalchemy-ext_1.3.22+ds1-1_i386.deb │ 2c510f25be018fca64077b84bbd86a8e 794976 python optional python3-sqlalchemy_1.3.22+ds1-1_all.deb ├── python-sqlalchemy-doc_1.3.22+ds1-1_all.deb │ ├── file list │ │ @@ -1,3 +1,3 @@ │ │ -rw-r--r-- 0 0 0 4 2020-12-30 16:25:19.000000 debian-binary │ │ --rw-r--r-- 0 0 0 11320 2020-12-30 16:25:19.000000 control.tar.xz │ │ --rw-r--r-- 0 0 0 2556056 2020-12-30 16:25:19.000000 data.tar.xz │ │ +-rw-r--r-- 0 0 0 11324 2020-12-30 16:25:19.000000 control.tar.xz │ │ +-rw-r--r-- 0 0 0 2556024 2020-12-30 16:25:19.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 │ │ │ │ @@ -215,23 +215,23 @@ │ │ │ │ │ │ │ │
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.
│ │ │ │basic_association.py - Illustrate a many-to-many relationship between an │ │ │ │ -“Order” and a collection of “Item” objects, associating a purchase price │ │ │ │ -with each via an association object called “OrderItem”
│ │ │ │ -proxied_association.py - Same example as basic_association, adding in
│ │ │ │ usage of sqlalchemy.ext.associationproxy
to make explicit references
│ │ │ │ to OrderItem
optional.
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.
│ │ │ │ +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_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.
│ │ │ │Large collection example.
│ │ │ │ @@ -389,24 +389,24 @@ │ │ │ │See also
│ │ │ │ │ │ │ │Listing of files:
__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
│ │ │ │ -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.
│ │ │ │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.
│ │ │ │ +bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number │ │ │ │ of rows in bulk.
│ │ │ │large_resultsets.py - In this series of tests, we are looking at time to load a large number │ │ │ │ of very small and simple rows.
│ │ │ │bulk_updates.py - This series of tests illustrates different ways to UPDATE a large number │ │ │ │ @@ -557,22 +557,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.
│ │ │ │ @@ -719,31 +719,31 @@ │ │ │ │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.py - Illustrates a method to intercept changes on objects, turning │ │ │ │ +
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 QueryEvents.before_compile()
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.
│ │ │ │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 │ │ │ │ +
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 QueryEvents.before_compile()
hook to limit queries
│ │ │ │ -to only the most recent version.
Illustrates “vertical table” mappings.
│ │ │ │ @@ -768,54 +768,54 @@ │ │ │ │ q = (session.query(Animal). │ │ │ │ filter(Animal.facts.any( │ │ │ │ and_(AnimalFact.key == u'weasel-like', │ │ │ │ AnimalFact.value == True)))) │ │ │ │ print('weasel-like animals', q.all())Listing of files:
dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
│ │ │ │ -dictlike.py - Mapping a vertical table as a dictionary.
│ │ │ │dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
│ │ │ │ +Working examples of single-table, joined-table, and concrete-table │ │ │ │ inheritance as described in Mapping Class Inheritance Hierarchies.
│ │ │ │Listing of files:
concrete.py - Concrete-table (table-per-class) inheritance example.
│ │ │ │single.py - Single-table (table-per-hierarchy) inheritance example.
│ │ │ │ -joined.py - Joined-table (table-per-subclass) inheritance example.
│ │ │ │single.py - Single-table (table-per-hierarchy) 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.