{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.qHveNKTb/b1/sqlalchemy_1.3.22+ds1-1_armhf.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.qHveNKTb/b2/sqlalchemy_1.3.22+ds1-1_armhf.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,5 +1,5 @@\n \n- 62c7f265c81fb665793f49ce59992512 2567484 doc optional python-sqlalchemy-doc_1.3.22+ds1-1_all.deb\n+ c4e36c5dd9ea1dfe90c6eadd554d74e9 2567540 doc optional python-sqlalchemy-doc_1.3.22+ds1-1_all.deb\n 17b0aedbfba8e073045390c1250bc39b 36332 debug optional python3-sqlalchemy-ext-dbgsym_1.3.22+ds1-1_armhf.deb\n db4152acc6cd2193bc979f85bc914d65 18568 python optional python3-sqlalchemy-ext_1.3.22+ds1-1_armhf.deb\n 2c510f25be018fca64077b84bbd86a8e 794976 python optional python3-sqlalchemy_1.3.22+ds1-1_all.deb\n"}, {"source1": "python-sqlalchemy-doc_1.3.22+ds1-1_all.deb", "source2": "python-sqlalchemy-doc_1.3.22+ds1-1_all.deb", "unified_diff": null, "details": [{"source1": "file list", "source2": "file list", "unified_diff": "@@ -1,3 +1,3 @@\n -rw-r--r-- 0 0 0 4 2020-12-30 16:25:19.000000 debian-binary\n -rw-r--r-- 0 0 0 11324 2020-12-30 16:25:19.000000 control.tar.xz\n--rw-r--r-- 0 0 0 2555968 2020-12-30 16:25:19.000000 data.tar.xz\n+-rw-r--r-- 0 0 0 2556024 2020-12-30 16:25:19.000000 data.tar.xz\n"}, {"source1": "control.tar.xz", "source2": "control.tar.xz", "unified_diff": null, "details": [{"source1": "control.tar", "source2": "control.tar", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "comments": ["Files differ"], "unified_diff": null}]}]}]}, {"source1": "data.tar.xz", "source2": "data.tar.xz", "unified_diff": null, "details": [{"source1": "data.tar", "source2": "data.tar", "unified_diff": null, "details": [{"source1": "./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html", "source2": "./usr/share/doc/python-sqlalchemy-doc/html/orm/examples.html", "comments": ["Ordering differences only"], "unified_diff": "@@ -215,26 +215,26 @@\n \n
Examples illustrating the usage of the \u201cassociation object\u201d pattern,\n where an intermediary class mediates the relationship between two\n classes that are associated in a many-to-many pattern.
\nListing of files:
proxied_association.py - Same example as basic_association, adding in\n-usage of sqlalchemy.ext.associationproxy
to make explicit references\n-to OrderItem
optional.
dict_of_sets_with_default.py - An advanced association proxy example which\n+illustrates nesting of association proxies to produce multi-level Python\n+collections, in this case a dictionary with string keys and sets of integers\n+as values, which conceal the underlying mapped classes.
\nbasic_association.py - Illustrate a many-to-many relationship between an\n \u201cOrder\u201d and a collection of \u201cItem\u201d objects, associating a purchase price\n with each via an association object called \u201cOrderItem\u201d
\ndict_of_sets_with_default.py - An advanced association proxy example which\n-illustrates nesting of association proxies to produce multi-level Python\n-collections, in this case a dictionary with string keys and sets of integers\n-as values, which conceal the underlying mapped classes.
\n+proxied_association.py - Same example as basic_association, adding in\n+usage of sqlalchemy.ext.associationproxy
to make explicit references\n+to OrderItem
optional.
An example of persistence for a directed graph structure. The\n@@ -272,37 +272,37 @@\n subclassing the HasAddresses
mixin, which ensures that the\n parent class is provided with an addresses
collection\n which contains Address
objects.
The discriminator_on_association.py and generic_fk.py scripts\n are modernized versions of recipes presented in the 2007 blog post\n Polymorphic Associations with SQLAlchemy.
\nListing of files:
table_per_association.py - Illustrates a mixin which provides a generic association\n-via a individually generated association tables for each parent class.\n-The associated objects themselves are persisted in a single table\n-shared among all parents.
\n-discriminator_on_association.py - Illustrates a mixin which provides a generic association\n using a single target table and a single association table,\n referred to by all parent tables. The association table\n contains a \u201cdiscriminator\u201d column which determines what type of\n parent object associates to each particular row in the association\n table.
\ntable_per_related.py - Illustrates a generic association which persists association\n-objects within individual tables, each one generated to persist\n-those objects on behalf of a particular parent class.
\n+table_per_association.py - Illustrates a mixin which provides a generic association\n+via a individually generated association tables for each parent class.\n+The associated objects themselves are persisted in a single table\n+shared among all parents.
\ngeneric_fk.py - Illustrates a so-called \u201cgeneric foreign key\u201d, in a similar fashion\n to that of popular frameworks such as Django, ROR, etc. This\n approach bypasses standard referential integrity\n practices, in that the \u201cforeign key\u201d column is not actually\n constrained to refer to any particular table; instead,\n in-application logic is used to determine which table is referenced.
\ntable_per_related.py - Illustrates a generic association which persists association\n+objects within individual tables, each one generated to persist\n+those objects on behalf of a particular parent class.
\n+Large collection example.
\nIllustrates the options to use with\n@@ -389,33 +389,33 @@\n
See also
\n \nListing of files:
large_resultsets.py - In this series of tests, we are looking at time to load a large number\n+of very small and simple rows.
\n+bulk_updates.py - This series of tests illustrates different ways to UPDATE a large number\n of rows in bulk.
\nshort_selects.py - This series of tests illustrates different ways to SELECT a single\n record by primary key
\n__main__.py - Allows the examples/performance package to be run as a script.
\n-bulk_inserts.py - This series of tests illustrates different ways to INSERT a large number\n of rows in bulk.
\n__main__.py - Allows the examples/performance package to be run as a script.
\n+single_inserts.py - In this series of tests, we\u2019re looking at a method that inserts a row\n within a distinct transaction, and afterwards returns to essentially a\n \u201cclosed\u201d state. This would be analogous to an API call that starts up\n a database connection, inserts the row, commits and closes.
\nlarge_resultsets.py - In this series of tests, we are looking at time to load a large number\n-of very small and simple rows.
\n-This is the default form of run:
\n$ python -m examples.performance single_inserts\n@@ -557,22 +557,22 @@\n
Examples of various relationship()
configurations,\n which make use of the primaryjoin
argument to compose special types\n of join conditions.
Listing of files:
threeway.py - Illustrate a \u201cthree way join\u201d - where a primary table joins to a remote\n-table via an association table, but then the primary table also needs\n-to refer to some columns in the remote table directly.
\n-cast.py - Illustrate a relationship()
that joins two columns where those\n columns are not of the same type, and a CAST must be used on the SQL\n side in order to match them.
threeway.py - Illustrate a \u201cthree way join\u201d - where a primary table joins to a remote\n+table via an association table, but then the primary table also needs\n+to refer to some columns in the remote table directly.
\n+A Space Invaders game using SQLite as the state machine.
\nOriginally developed in 2012. Adapted to work in Python 3.
\n@@ -702,48 +702,48 @@\n assert type(other) is SomeClass and other.id == self.idAbove, if two instance of SomeClass
with the same version identifier\n are updated and sent to the database for UPDATE concurrently, if the database\n isolation level allows the two UPDATE statements to proceed, one will fail\n because it no longer is against the last known version identifier.
Listing of files:
history_meta.py - Versioned mixin class and other utilities.
\n-test_versioning.py - Unit tests illustrating usage of the history_meta.py
\n module functions.
history_meta.py - Versioned mixin class and other utilities.
\n+Several examples that illustrate the technique of intercepting changes\n that would be first interpreted as an UPDATE on a row, and instead turning\n it into an INSERT of a new row, leaving the previous row intact as\n a historical version.
\nCompare to the Versioning with a History Table example which writes a\n history row to a separate history table.
\nListing of files:
versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning\n+an UPDATE statement on a single row into an INSERT statement, so that a new\n+row is inserted with the new data, keeping the old row intact.
\n+versioned_rows.py - Illustrates a method to intercept changes on objects, turning\n+an UPDATE statement on a single row into an INSERT statement, so that a new\n+row is inserted with the new data, keeping the old row intact.
\n+versioned_map.py - A variant of the versioned_rows example built around the\n concept of a \u201cvertical table\u201d structure, like those illustrated in\n Vertical Attribute Mapping examples.
\nversioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique of versioned_rows.py
,\n but also emits an UPDATE on the old row to affect a change in timestamp.\n Also includes a QueryEvents.before_compile()
hook to limit queries\n to only the most recent version.
versioned_rows_w_versionid.py - Illustrates a method to intercept changes on objects, turning\n-an UPDATE statement on a single row into an INSERT statement, so that a new\n-row is inserted with the new data, keeping the old row intact.
\n-versioned_rows.py - Illustrates a method to intercept changes on objects, turning\n-an UPDATE statement on a single row into an INSERT statement, so that a new\n-row is inserted with the new data, keeping the old row intact.
\n-Illustrates \u201cvertical table\u201d mappings.
\n@@ -768,54 +768,54 @@\n q = (session.query(Animal).\n filter(Animal.facts.any(\n and_(AnimalFact.key == u'weasel-like',\n AnimalFact.value == True))))\n print('weasel-like animals', q.all())Listing of files:
dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
\n-dictlike.py - Mapping a vertical table as a dictionary.
\ndictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
\n+Working examples of single-table, joined-table, and concrete-table\n inheritance as described in Mapping Class Inheritance Hierarchies.
\nListing of files:
concrete.py - Concrete-table (table-per-class) inheritance example.
\nsingle.py - Single-table (table-per-hierarchy) inheritance example.
\n-joined.py - Joined-table (table-per-subclass) inheritance example.
\nsingle.py - Single-table (table-per-hierarchy) inheritance example.
\n+Examples illustrating modifications to SQLAlchemy\u2019s attribute management\n system.
\nListing of files:
listen_for_events.py - Illustrates how to attach events to all instrumented attributes\n+and listen for change events.
\n+active_column_defaults.py - Illustrates use of the AttributeEvents.init_scalar()
\n event, in conjunction with Core column defaults to provide\n ORM objects that automatically produce the default value\n when an un-set attribute is accessed.
listen_for_events.py - Illustrates how to attach events to all instrumented attributes\n-and listen for change events.
\n-custom_management.py - Illustrates customized class instrumentation, using\n the sqlalchemy.ext.instrumentation
extension package.