{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.ub1oUsXD/b1/sqlalchemy_1.3.22+ds1-1_i386.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.ub1oUsXD/b2/sqlalchemy_1.3.22+ds1-1_i386.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,5 +1,5 @@\n \n- 8aa9964097deb3d79961600394dcd2be 2567568 doc optional python-sqlalchemy-doc_1.3.22+ds1-1_all.deb\n+ 2bbf707c43a2a305a3aa195894d2b24c 2567540 doc optional python-sqlalchemy-doc_1.3.22+ds1-1_all.deb\n b2cc03740fda8c79971ac65a2a30fcb6 33352 debug optional python3-sqlalchemy-ext-dbgsym_1.3.22+ds1-1_i386.deb\n 9b86b9d86d09f09c76edbe04efabca40 20196 python optional python3-sqlalchemy-ext_1.3.22+ds1-1_i386.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 11320 2020-12-30 16:25:19.000000 control.tar.xz\n--rw-r--r-- 0 0 0 2556056 2020-12-30 16:25:19.000000 data.tar.xz\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 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,23 +215,23 @@\n \n
\n

Associations\u00b6

\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.

\n

Listing of files:

\n

\n
\n@@ -279,29 +279,29 @@\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.

    \n

  • \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.

    \n+
  • 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.

    \n

  • \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.

    \n

  • \n-
  • 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.

    \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.

    \n

  • \n \n

    \n \n
    \n

    Large Collections\u00b6

    \n

    Large collection example.

    \n@@ -389,24 +389,24 @@\n
    \n

    See also

    \n

    How can I profile a SQLAlchemy powered application?

    \n
    \n
    \n

    File Listing\u00b6

    \n

    Listing of files:

    \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

    \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@@ -719,31 +719,31 @@\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.

    \n

    Compare to the Versioning with a History Table example which writes a\n history row to a separate history table.

    \n

    Listing of files:

    \n

    \n
    \n
    \n
    \n

    Vertical Attribute Mapping\u00b6

    \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())
    \n \n

    Listing of files:

    \n

    \n \n \n
    \n

    Inheritance Mapping Recipes\u00b6

    \n
    \n

    Basic Inheritance Mappings\u00b6

    \n

    Working examples of single-table, joined-table, and concrete-table\n inheritance as described in Mapping Class Inheritance Hierarchies.

    \n

    Listing of files:

    \n

    \n
    \n
    \n
    \n

    Special APIs\u00b6

    \n
    \n

    Attribute Instrumentation\u00b6

    \n

    Examples illustrating modifications to SQLAlchemy\u2019s attribute management\n system.

    \n

    Listing of files:

    \n

    \n
    \n
    \n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -75,21 +75,21 @@\n Listing of files:\n * adjacency_list.py\n **** Associations\u00b6 ****\n Examples illustrating the usage of the \u201cassociation object\u201d pattern, where an\n intermediary class mediates the relationship between two classes that are\n associated in a many-to-many pattern.\n Listing of files:\n- * dict_of_sets_with_default.py - An advanced association proxy example\n- which illustrates nesting of association proxies to produce multi-level\n- Python collections, in this case a dictionary with string keys and sets\n- of integers as values, which conceal the underlying mapped classes.\n-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 with\n-each via an association object called \u201cOrderItem\u201d\n+ * 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+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 as\n+values, which conceal the underlying mapped classes.\n proxied_association.py - Same example as basic_association, adding in usage of\n sqlalchemy.ext.associationproxy to make explicit references to OrderItem\n optional.\n **** Directed Graphs\u00b6 ****\n An example of persistence for a directed graph structure. The graph is stored\n as a collection of edges, each referencing both a \u201clower\u201d and an \u201cupper\u201d node\n in a table of nodes. Basic persistence and querying for lower- and upper-\n@@ -119,26 +119,26 @@\n with_SQLAlchemy.\n Listing of files:\n * discriminator_on_association.py - Illustrates a mixin which provides a\n generic association using a single target table and a single association\n table, referred to by all parent tables. The association table contains a\n \u201cdiscriminator\u201d column which determines what type of parent object\n associates to each particular row in the association table.\n-table_per_association.py - Illustrates a mixin which provides a generic\n-association via a individually generated association tables for each parent\n-class. The associated objects themselves are persisted in a single table shared\n-among all parents.\n+table_per_related.py - Illustrates a generic association which persists\n+association objects within individual tables, each one generated to persist\n+those objects on behalf of a particular parent class.\n generic_fk.py - Illustrates a so-called \u201cgeneric foreign key\u201d, in a similar\n fashion to that of popular frameworks such as Django, ROR, etc. This approach\n bypasses standard referential integrity practices, in that the \u201cforeign key\u201d\n column is not actually constrained to refer to any particular table; instead,\n in-application logic is used to determine which table is referenced.\n-table_per_related.py - Illustrates a generic association which persists\n-association 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\n+association via a individually generated association tables for each parent\n+class. The associated objects themselves are persisted in a single table shared\n+among all parents.\n **** Large Collections\u00b6 ****\n Large collection example.\n Illustrates the options to use with relationship() when the list of related\n objects is very large, including:\n * \u201cdynamic\u201d relationships which query slices of data as accessed\n * how to use ON DELETE CASCADE in conjunction with passive_deletes=True to\n greatly improve the performance of related collection deletion.\n@@ -196,22 +196,22 @@\n $ python -m examples.performance bulk_inserts \\\n --dburl mysql+mysqldb://scott:tiger@localhost/test \\\n --profile --num 1000\n See also\n How_can_I_profile_a_SQLAlchemy_powered_application?\n *** File Listing\u00b6 ***\n Listing of files:\n- * __main__.py - Allows the examples/performance package to be run as a\n- script.\n+ * single_inserts.py - In this series of tests, we\u2019re looking at a method\n+ that inserts a row within a distinct transaction, and afterwards returns\n+ to essentially a \u201cclosed\u201d state. This would be analogous to an API call\n+ that starts up a database connection, inserts the row, commits and\n+ closes.\n short_selects.py - This series of tests illustrates different ways to SELECT a\n single record by primary key\n-single_inserts.py - In this series of tests, we\u2019re looking at a method that\n-inserts a row within a distinct transaction, and afterwards returns to\n-essentially a \u201cclosed\u201d state. This would be analogous to an API call that\n-starts up a database connection, inserts the row, commits and closes.\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\n large number of rows in bulk.\n large_resultsets.py - In this series of tests, we are looking at time to load a\n large number of very small and simple rows.\n bulk_updates.py - This series of tests illustrates different ways to UPDATE a\n large number of rows in bulk.\n *** Running all tests with time\u00b6 ***\n@@ -354,20 +354,20 @@\n total time 2.754592 sec\n test_subqueryload : load everything, subquery eager loading. (1000 iterations);\n total time 2.977696 sec\n **** Relationship Join Conditions\u00b6 ****\n Examples of various relationship() configurations, which make use of the\n primaryjoin argument to compose special types 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 side\n- in order to match them.\n-threeway.py - Illustrate a \u201cthree way join\u201d - where a primary table joins to a\n-remote table via an association table, but then the primary table also needs to\n-refer to some columns in the remote table directly.\n+ * threeway.py - Illustrate a \u201cthree way join\u201d - where a primary table joins\n+ to a remote table via an association table, but then the primary table\n+ also needs 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 side in\n+order to match them.\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 Runs in a textual console using ASCII art.\n [orm/space_invaders.jpg]\n To run:\n python -m examples.space_invaders.space_invaders\n@@ -481,27 +481,28 @@\n Several examples that illustrate the technique of intercepting changes that\n would be first interpreted as an UPDATE on a row, and instead turning it into\n an INSERT of a new row, leaving the previous row intact as a historical\n version.\n Compare to the Versioning_with_a_History_Table example which writes a history\n row to a separate history table.\n Listing of files:\n- * versioned_rows.py - Illustrates a method to intercept changes on objects,\n- turning an UPDATE statement on a single row into an INSERT statement, so\n- that a new 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 Vertical\n-Attribute_Mapping examples.\n+ * versioned_update_old_row.py - Illustrates the same UPDATE into INSERT\n+ technique of versioned_rows.py, but also emits an UPDATE on the old row\n+ to affect a change in timestamp. Also includes a\n+ QueryEvents.before_compile() hook to limit queries to only the most\n+ recent version.\n versioned_rows_w_versionid.py - Illustrates a method to intercept changes on\n objects, turning an UPDATE statement on a single row into an INSERT statement,\n so that a new row is inserted with the new data, keeping the old row intact.\n-versioned_update_old_row.py - Illustrates the same UPDATE into INSERT technique\n-of versioned_rows.py, but also emits an UPDATE on the old row to affect a\n-change in timestamp. Also includes a QueryEvents.before_compile() hook to limit\n-queries to only the most recent version.\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 Vertical\n+Attribute_Mapping examples.\n+versioned_rows.py - Illustrates a method to intercept changes on objects,\n+turning an UPDATE statement on a single row into an INSERT statement, so that a\n+new row is inserted with the new data, keeping the old row intact.\n **** Vertical Attribute Mapping\u00b6 ****\n Illustrates \u201cvertical table\u201d mappings.\n A \u201cvertical table\u201d refers to a technique where individual attributes of an\n object are stored as distinct rows in a table. The \u201cvertical table\u201d technique\n is used to persist objects which can have a varied set of attributes, at the\n expense of simple query control and brevity. It is commonly found in content/\n document management systems in order to represent user-created structures\n@@ -520,36 +521,35 @@\n \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())\n Listing of files:\n- * dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as\n- a dictionary.\n-dictlike.py - Mapping a vertical table as a dictionary.\n+ * dictlike.py - Mapping a vertical table as a dictionary.\n+dictlike-polymorphic.py - Mapping a polymorphic-valued vertical table as a\n+dictionary.\n ***** Inheritance Mapping Recipes\u00b6 *****\n **** Basic Inheritance Mappings\u00b6 ****\n Working examples of single-table, joined-table, and concrete-table inheritance\n as described in Mapping_Class_Inheritance_Hierarchies.\n Listing of files:\n * concrete.py - Concrete-table (table-per-class) inheritance example.\n-single.py - Single-table (table-per-hierarchy) inheritance example.\n joined.py - Joined-table (table-per-subclass) inheritance example.\n+single.py - Single-table (table-per-hierarchy) inheritance example.\n ***** Special APIs\u00b6 *****\n **** Attribute Instrumentation\u00b6 ****\n Examples illustrating modifications to SQLAlchemy\u2019s attribute management\n system.\n Listing of files:\n- * active_column_defaults.py - Illustrates use of the\n- AttributeEvents.init_scalar() event, in conjunction with Core column\n- defaults to provide ORM objects that automatically produce the default\n- value when an un-set attribute is accessed.\n-listen_for_events.py - Illustrates how to attach events to all instrumented\n-attributes and listen for change events.\n+ * listen_for_events.py - Illustrates how to attach events to all\n+ instrumented attributes 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 ORM objects that\n+automatically produce the default value when an un-set attribute is accessed.\n custom_management.py - Illustrates customized class instrumentation, using the\n sqlalchemy.ext.instrumentation extension package.\n **** Horizontal Sharding\u00b6 ****\n A basic example of using the SQLAlchemy Sharding API. Sharding refers to\n horizontally scaling data across multiple databases.\n The basic components of a \u201csharded\u201d mapping are:\n * multiple databases, each assigned a \u2018shard id\u2019\n"}]}]}]}]}]}