{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.EavwGKyb/b1/sqlalchemy_1.4.50+ds1-1_amd64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.EavwGKyb/b2/sqlalchemy_1.4.50+ds1-1_amd64.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,5 +1,5 @@\n \n- ed964aff8e77b943989a5917e2858f73 3720076 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb\n+ 3f67245a2ffb1f76d0a6e36142d10a7b 3720016 doc optional python-sqlalchemy-doc_1.4.50+ds1-1_all.deb\n 397dc71818c832a10795aefe2fa8bcbb 70296 debug optional python3-sqlalchemy-ext-dbgsym_1.4.50+ds1-1_amd64.deb\n 3b41bed8e1bb07c1668ba0caa003f1cc 20936 python optional python3-sqlalchemy-ext_1.4.50+ds1-1_amd64.deb\n 7b9b7746123a45060be2c12bd6e80ed4 1009400 python optional python3-sqlalchemy_1.4.50+ds1-1_all.deb\n"}, {"source1": "python-sqlalchemy-doc_1.4.50+ds1-1_all.deb", "source2": "python-sqlalchemy-doc_1.4.50+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 2024-01-05 13:47:47.000000 debian-binary\n -rw-r--r-- 0 0 0 13376 2024-01-05 13:47:47.000000 control.tar.xz\n--rw-r--r-- 0 0 0 3706508 2024-01-05 13:47:47.000000 data.tar.xz\n+-rw-r--r-- 0 0 0 3706448 2024-01-05 13:47:47.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": "@@ -308,46 +308,46 @@\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. Listing of files: basic_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\u201dAssociations\u00b6
\n \n-
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.
\nproxied_association.py - Same example as basic_association, adding in\n usage of sqlalchemy.ext.associationproxy
to make explicit references\n to OrderItem
optional.
basic_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
\n+Examples illustrating the asyncio engine feature of SQLAlchemy.
\nListing of files:
async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n-for asynchronous ORM use.
\n-gather_orm_statements.py - Illustrates how to run many statements concurrently using asyncio.gather()
\n along many asyncio database connections, merging ORM results into a single\n AsyncSession
.
greenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n-for asynchronous ORM use, including the optional run_sync() method.
\n+async_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n+for asynchronous ORM use.
\nbasic.py - Illustrates the asyncio engine / connection interface.
\ngreenlet_orm.py - Illustrates use of the sqlalchemy.ext.asyncio.AsyncSession object\n+for asynchronous ORM use, including the optional run_sync() method.
\n+An example of persistence for a directed graph structure. The\n graph is stored as a collection of edges, each referencing both a\n@@ -388,32 +388,32 @@\n are modernized versions of recipes presented in the 2007 blog post\n Polymorphic Associations with SQLAlchemy.
\nListing of files:
table_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.
\ntable_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+generic_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.
\ndiscriminator_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.
\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.
\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.
\nLarge collection example.
\n@@ -503,30 +503,30 @@\n \nListing of files:
bulk_updates.py - This series of tests will illustrate different ways to UPDATE a large number\n of rows in bulk (under construction! there\u2019s just one test at the moment)
\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-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.
\nbulk_inserts.py - This series of tests illustrates different ways to INSERT a large number\n+of rows in bulk.
\n+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+__main__.py - Allows the examples/performance package to be run as a script.
\nshort_selects.py - This series of tests illustrates different ways to SELECT a single\n record by primary key
\nbulk_inserts.py - This series of tests illustrates different ways to INSERT a large number\n-of rows in bulk.
\n-This is the default form of run:
\n$ python -m examples.performance single_inserts\n@@ -668,22 +668,22 @@\n \n \n Relationship Join Conditions\u00b6
\n Examples of various relationship()
configurations,\n which make use of the primaryjoin
argument to compose special types\n of join conditions.
\n Listing of files:
\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.
\n- \n 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 \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.
\n+ \n
\n \n \n \n Space Invaders\u00b6
\n A Space Invaders game using SQLite as the state machine.
\n Originally developed in 2012. Adapted to work in Python 3.
\n@@ -838,23 +838,23 @@\n concept of a \u201cvertical table\u201d structure, like those illustrated in\n Vertical Attribute Mapping examples.\n \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 \n+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+ \n versioned_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 SessionEvents.do_orm_execute()
hook to limit queries\n to only the most recent version.
\n \n-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- \n \n \n \n \n \n Vertical Attribute Mapping\u00b6
\n Illustrates \u201cvertical table\u201d mappings.
\n@@ -879,57 +879,57 @@\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.py - Mapping a vertical table as a dictionary.
\n-dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a dictionary.
\ndictlike.py - Mapping a 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:
single.py - Single-table (table-per-hierarchy) inheritance example.
\n+concrete.py - Concrete-table (table-per-class) inheritance example.
\njoined.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:
custom_management.py - Illustrates customized class instrumentation, using\n-the sqlalchemy.ext.instrumentation
extension package.
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.
\ncustom_management.py - Illustrates customized class instrumentation, using\n+the sqlalchemy.ext.instrumentation
extension package.
A basic example of using the SQLAlchemy Sharding API.\n Sharding refers to horizontally scaling data across multiple\n@@ -958,21 +958,21 @@\n
The construction of generic sharding routines is an ambitious approach\n to the issue of organizing instances among multiple databases. For a\n more plain-spoken alternative, the \u201cdistinct entity\u201d approach\n is a simple method of assigning objects to different tables (and potentially\n database nodes) in an explicit way - described on the wiki at\n EntityName.
\nListing of files:
separate_databases.py - Illustrates sharding using distinct SQLite databases.
\n+separate_tables.py - Illustrates sharding using a single SQLite database, that will however\n+have multiple tables using a naming convention.
\nseparate_schema_translates.py - Illustrates sharding using a single database with multiple schemas,\n where a different \u201cschema_translates_map\u201d can be used for each shard.
\nseparate_tables.py - Illustrates sharding using a single SQLite database, that will however\n-have multiple tables using a naming convention.
\n+separate_databases.py - Illustrates sharding using distinct SQLite databases.
\n