{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.jWInkSw1/b1/libgnatcoll-db_23.0.0-4_armhf.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.jWInkSw1/b2/libgnatcoll-db_23.0.0-4_armhf.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,11 +1,11 @@\n \n  39f0e9a0162bbe91a55d248267ec83bf 362108 debug optional libgnatcoll-db-bin-dbgsym_23.0.0-4_armhf.deb\n  eedc94f0a60f3b883ba241216c352415 187976 devel optional libgnatcoll-db-bin_23.0.0-4_armhf.deb\n- 54f33a968fec059f9bdb410f518d91e6 453776 doc optional libgnatcoll-db-doc_23.0.0-4_all.deb\n+ 5280c8affe70c6db1084d8a7ea9152eb 453676 doc optional libgnatcoll-db-doc_23.0.0-4_all.deb\n  d95600bee6d885f88f0073cc341d2c73 211860 debug optional libgnatcoll-postgres1-dbgsym_23.0.0-4_armhf.deb\n  e5fd7e78f0b5729ffbd1120042d409b7 119384 libs optional libgnatcoll-postgres1_23.0.0-4_armhf.deb\n  07942b62f11d55906b49bf153e6ebb0e 142872 libdevel optional libgnatcoll-postgres3-dev_23.0.0-4_armhf.deb\n  46255c3dbfd0fb47d1dbce83afdb24c1 1843220 debug optional libgnatcoll-sql3-dbgsym_23.0.0-4_armhf.deb\n  3ebc9ca4ce972eda418a6ef9cddc9449 928684 libs optional libgnatcoll-sql3_23.0.0-4_armhf.deb\n  7450851f11b4ecc364220a0e5af519d3 1147524 libdevel optional libgnatcoll-sql5-dev_23.0.0-4_armhf.deb\n  da45a736181ce0c55eb8ff4a89f19439 50492 debug optional libgnatcoll-sqlite20-dbgsym_23.0.0-4_armhf.deb\n"}, {"source1": "libgnatcoll-db-doc_23.0.0-4_all.deb", "source2": "libgnatcoll-db-doc_23.0.0-4_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 2023-05-10 21:15:55.000000 debian-binary\n--rw-r--r--   0        0        0     1604 2023-05-10 21:15:55.000000 control.tar.xz\n--rw-r--r--   0        0        0   451980 2023-05-10 21:15:55.000000 data.tar.xz\n+-rw-r--r--   0        0        0     1600 2023-05-10 21:15:55.000000 control.tar.xz\n+-rw-r--r--   0        0        0   451884 2023-05-10 21:15:55.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": "file list", "source2": "file list", "unified_diff": "@@ -40,15 +40,15 @@\n -rw-r--r--   0 root         (0) root         (0)      607 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/objects.inv\n -rw-r--r--   0 root         (0) root         (0)     3886 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/search.html\n -rw-r--r--   0 root         (0) root         (0)    23062 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/searchindex.js\n -rw-r--r--   0 root         (0) root         (0)   184070 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/sql.html\n -rw-r--r--   0 root         (0) root         (0)    34287 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/xref.html\n drwxr-xr-x   0 root         (0) root         (0)        0 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/text/\n -rw-r--r--   0 root         (0) root         (0)     1169 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/text/index.txt\n--rw-r--r--   0 root         (0) root         (0)    31611 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/text/sql.txt.gz\n+-rw-r--r--   0 root         (0) root         (0)    31506 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/text/sql.txt.gz\n -rw-r--r--   0 root         (0) root         (0)     6534 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/text/xref.txt.gz\n drwxr-xr-x   0 root         (0) root         (0)        0 2023-05-10 21:15:55.000000 ./usr/share/doc-base/\n -rw-r--r--   0 root         (0) root         (0)      670 2023-05-10 21:09:43.000000 ./usr/share/doc-base/libgnatcoll-db-doc.gnatcoll-db\n lrwxrwxrwx   0 root         (0) root         (0)        0 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_static/_sphinx_javascript_frameworks_compat.js -> ../../../../javascript/sphinxdoc/1.0/_sphinx_javascript_frameworks_compat.js\n lrwxrwxrwx   0 root         (0) root         (0)        0 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_static/css/badge_only.css -> ../../../../../sphinx_rtd_theme/static/css/badge_only.css\n lrwxrwxrwx   0 root         (0) root         (0)        0 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_static/css/theme.css -> ../../../../../sphinx_rtd_theme/static/css/theme.css\n lrwxrwxrwx   0 root         (0) root         (0)        0 2023-05-10 21:15:55.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_static/doctools.js -> ../../../../javascript/sphinxdoc/1.0/doctools.js\n"}, {"source1": "./usr/share/doc/libgnatcoll-db-doc/text/sql.txt.gz", "source2": "./usr/share/doc/libgnatcoll-db-doc/text/sql.txt.gz", "unified_diff": null, "details": [{"source1": "sql.txt", "source2": "sql.txt", "unified_diff": "@@ -31,33 +31,33 @@\n   this place is organized into tables, each of which contains a number\n   of fields. A row in a table represents one object. The set of tables\n   and their fields is called the **schema** of the database.\n \n Traditionally, writing the SQL queries is done inline: special markers\n are inserted into your code to delimit sections that contain SQL code\n (as opposed to Ada code), and these are then preprocessed to generate\n-actual code. This isn\u2019t the approach chosen in GNATColl: there are\n+actual code. This isn't the approach chosen in GNATColl: there are\n several drawbacks, in particular your code is no longer Ada and\n various tools will choke on it.\n \n The other usual approach is to write the queries as strings, which are\n passed, via a DBMS-specific API, to the DBMS server. This approach is\n very fragile:\n \n * The string might not contain **well-formed** SQL. This will\n   unfortunately only be detected at run time when the DBMS complains.\n \n * This is not **type safe**. You might be comparing a text field with\n   an integer, for instance. In some cases, the DBMS will accept that\n-  (sqlite for instance), but in some other cases it won\u2019t\n+  (sqlite for instance), but in some other cases it won't\n   (PostgreSQL). The result might then either raise an error, or return\n   an empty list.\n \n * There is a risk of **SQL injection**. Assuming the string is\n-  constructed dynamically (using Ada\u2019s *&* operator), it might be easy\n+  constructed dynamically (using Ada's *&* operator), it might be easy\n   for a user to pass a string that breaks the query, and even destroys\n   things in the database.\n \n * As discussed previously, the SQL code might not be **portable**\n   across DBMS. For instance, creating an automatically increment\n   integer primary key in a table is DBMS specific.\n \n@@ -158,15 +158,15 @@\n 1.2. Database example\n =====================\n \n This section describes an example that will be extended throughout\n this chapter. We will build an application that represents a library.\n Such a library contains various media (books and DVDs for instance),\n and customers. A customer can borrow multiple media at the same time,\n-but a media is either at a customer\u2019s, or still in the library.\n+but a media is either at a customer's, or still in the library.\n \n The GNATColl distribution includes an example directory which contains\n all the code and data for this example.\n \n \n 1.3. Database schema\n ====================\n@@ -182,15 +182,15 @@\n fully described later (The gnatcoll_db2ada tool). However, the input\n is always the same: this is the schema of your database, that is the\n list of tables and fields that make up your database. There exist two\n ways to provide that information:\n \n * From a running database\n \n-  If you pass the DBMS vendor (postgresql, sqlite,\u2026) and the\n+  If you pass the DBMS vendor (postgresql, sqlite,...) and the\n   connection parameters to *gnatcoll_db2ada*, it is able to query the\n   schema on its own. However, this should not be the preferred method:\n   this is similar to reverse engineering assembly code into the\n   original high-level code, and some semantic information will be\n   missing. For instance, in SQL we have to create tables just to\n   represent the many-to-many relationships. These extra tables are\n   part of the implementation of the schema, but are just noise when it\n@@ -208,124 +208,124 @@\n   below and the ORM).\n \n   The most convenient editor for this file is Emacs, using the *org-\n   mode* which provides convenient key shortcuts for editing the\n   contents of ASCII tables. But any text editor will do, and you do\n   not need to align the columns in this file.\n \n-  All lines starting with a hash sign (\u2018#\u2019) will be ignored.\n+  All lines starting with a hash sign ('#') will be ignored.\n \n   This file is a collection of ASCII tables, each of which relates to\n   one table or one SQL view in your database. The paragraphs start\n   with a line containing:\n \n      table ::=\n         '|' ('ABSTRACT')? ('TABLE'|'VIEW') ['(' supertable ')']\n         '|' <name> '|' <name_row>\n \n-  \u201cname\u201d is the name of the table. The third pipe and third column are\n+  \"name\" is the name of the table. The third pipe and third column are\n   optional, and should be used to specify the name for the element\n   represented by a single row. For instance, if the table is called\n-  \u201cbooks\u201d, the third column could contain \u201cbook\u201d. This is used when\n+  \"books\", the third column could contain \"book\". This is used when\n   generating objects for use with *GNATCOLL.SQL.ORM*.\n \n   If the first line starts with the keyword *ABSTRACT*, then no\n   instance of that table actually exists in the database. This is used\n   in the context of table inheritance, so define shared fields only\n   once among multiple tables.\n \n   The keyword *TABLE* can be followed by the name of a table from\n   which it inherits the fields. Currently, that supertable must be\n   abstract, and the fields declared in that table are simply\n   duplicated in the new table.\n \n   Following the declaration of the table, the file then describe their\n   fields, each on a separate line. Each of these lines must start with\n-  a pipe character (\u201c|\u201d), and contain a number of pipe-separated\n+  a pipe character (\"|\"), and contain a number of pipe-separated\n   fields. The order of the fields is always given by the following\n   grammar:\n \n      fields ::=\n         '|' <name> '|' <type>\n         '|' ('PK'|''|'NULL'|'NOT NULL'|'INDEX'|'UNIQUE'|'NOCASE')\n         '|' [default] '|' [doc] '|'\n \n-  The type of the field is the SQL type (\u201cINTEGER\u201d, \u201cTEXT\u201d,\n-  \u201cTIMESTAMP\u201d, \u201cDATE\u201d, \u201cDOUBLE PRECISION\u201d, \u201cMONEY\u201d, \u201cBOOLEAN\u201d, \u201cTIME\u201d,\n-  \u201cCHARACTER(1)\u201d). Any maximal length can be specified for strings,\n+  The type of the field is the SQL type (\"INTEGER\", \"TEXT\",\n+  \"TIMESTAMP\", \"DATE\", \"DOUBLE PRECISION\", \"MONEY\", \"BOOLEAN\", \"TIME\",\n+  \"CHARACTER(1)\"). Any maximal length can be specified for strings,\n   not just 1 as in this example. The tool will automatically convert\n   these to Ada when generating Ada code. A special type\n-  (\u201cAUTOINCREMENT\u201d) is an integer that is automatically incremented\n+  (\"AUTOINCREMENT\") is an integer that is automatically incremented\n   according to available ids in the table. The exact type used will\n   depend on the specific DBMS.\n \n-  The property \u2018NOCASE\u2019 indicates that comparison should be case\n+  The property 'NOCASE' indicates that comparison should be case\n   insensitive for this field.\n \n   If the field is a foreign key (that is a value that must correspond\n   to a row in another table), you can use the special syntax for its\n   type:\n \n      fk_type ::= 'FK' <table_name> [ '(' <reverse_name> ')' ]\n \n   As you can see, the type of the field is not specified explicitly,\n-  but will always be that of the foreign table\u2019s primary key. With\n+  but will always be that of the foreign table's primary key. With\n   this syntax, the foreign table must have a single field for its\n   primary key. GNATColl does not force a specific order for the\n   declaration of tables: if is valid to have a foreign key to a table\n-  that hasn\u2019t been declared yet. There is however a restriction if you\n+  that hasn't been declared yet. There is however a restriction if you\n   use the model to create a sqlite database (through the *-createdb*\n   switch of *gnatcoll_db2ada*): in this case, a reference to a table\n-  that hasn\u2019t been defined yet may not be not through a field marked\n+  that hasn't been defined yet may not be not through a field marked\n   as NOT NULL. This is a limitation of the sqlite backend itself. The\n   solution in this case is to reorder the declaration of tables, or\n   drop the NOT NULL constraint.\n \n   Another restriction is that a foreign key that is also a primary key\n   must reference a table that has already been defined. You need to\n   reorder the declaration of your tables to ensure this is the case.\n \n-  \u201creverse_name\u201d is the optional name that will be generated in the\n+  \"reverse_name\" is the optional name that will be generated in the\n   Ada code for the reverse relationship, in the context of\n-  *GNATCOLL.SQL.ORM*. If the \u201creverse_name\u201d is empty (the parenthesis\n+  *GNATCOLL.SQL.ORM*. If the \"reverse_name\" is empty (the parenthesis\n   are shown), no reverse relationship is generated. If the parenthesis\n   and the reverse_name are both omitted, a default name is generated\n   based on the name of the field.\n \n   The third column in the fields definition indicates the constraints\n   of the type. Multiple keywords can be used if they are separated by\n-  commas. Thus, \u201cNOT NULL, INDEX\u201d indicates a column that must be set\n+  commas. Thus, \"NOT NULL, INDEX\" indicates a column that must be set\n   by the user, and for which an index is created to speed up look ups.\n \n-  * A primary key (\u201cPK\u201d)\n+  * A primary key (\"PK\")\n \n-  * The value must be defined (\u201cNOT NULL\u201d)\n+  * The value must be defined (\"NOT NULL\")\n \n-  * The value can be left undefined (\u201cNULL\u201d)\n+  * The value can be left undefined (\"NULL\")\n \n-  * A unique constraint and index (\u201cUNIQUE\u201d)\n+  * A unique constraint and index (\"UNIQUE\")\n \n-  * An index should be created for that column (\u201cINDEX\u201d) to speed up\n+  * An index should be created for that column (\"INDEX\") to speed up\n     the lookups.\n \n   * The automatic index created for a Foreign Key should not be\n-    created (\u201cNOINDEX\u201d). Every time a field references another table,\n+    created (\"NOINDEX\"). Every time a field references another table,\n     GNATColl will by default create an index for it, so that the ORM\n-    can more efficiently do a reverse query (from the target table\u2019s\n+    can more efficiently do a reverse query (from the target table's\n     row find all the rows in the current table that reference that\n     target row). This will in general provide more efficiency, but in\n     some cases you never intend to do the reverse query and thus can\n     spare the extra index.\n \n   The fourth column gives the default value for the field, and is\n   given in SQL syntax. Strings must be quoted with single quotes.\n \n   The fifth column contains documentation for the field (if any). This\n   documentation will be included in the generated code, so that IDEs\n-  can provide useful tooltips when navigating your application\u2019s code.\n+  can provide useful tooltips when navigating your application's code.\n \n   After all the fields have been defined, you can specify extract\n   constraints on the table. In particular, if you have a foreign key\n   to a table that uses a tuple as its primary key, you can define that\n   foreign key on a new line, as:\n \n      FK ::= '|' \"FK:\" '|' <table> '|' <field_names>*\n@@ -347,37 +347,37 @@\n   The same way the unique multi-column constraint and index can be\n   created. The name is optional.\n \n         TABLE | tableA |\n         UNIQUE: | field1,field2,field3 | name |\n \n   Going back to the example we described earlier (Database example),\n-  let\u2019s describe the tables that are involved.\n+  let's describe the tables that are involved.\n \n   The first table contains the customers. Here is its definition:\n \n      | TABLE | customers     | customer        || The customer for the library |\n      | id    | AUTOINCREMENT | PK              || Auto-generated id            |\n      | first | TEXT          | NOT NULL        || Customer's first name        |\n      | last  | TEXT          | NOT NULL, INDEX || Customer's last name         |\n \n   We highly recommend to set a primary key on all tables. This is a\n   field whose value is unique in the table, and thus that can act as\n   an identifier for a specific row in the table (in this case for a\n   specific customer). We recommend using integers for these ids for\n   efficiency reasons. It is possible that the primary key will be made\n-  of several fields, in which case they should all have the \u201cPK\u201d\n+  of several fields, in which case they should all have the \"PK\"\n   constraint in the third column.\n \n   A table with no primary key is still usable. The difference is in\n   the code generated for the ORM (The Object-Relational Mapping layer\n   (ORM)), since the *Delete* operation for this table will raise a\n-  *Program_Error* instead of doing the actual deletion (that\u2019s because\n+  *Program_Error* instead of doing the actual deletion (that's because\n   there is no guaranteed unique identifier for the element, so the ORM\n-  does not know which one to delete \u2013 we do not depend on having\n+  does not know which one to delete -- we do not depend on having\n   unique internal ids on the table, like some DBMS have). Likewise,\n   the elements extracted from such a primary key-less table will not\n   be cached locally in the session, and cannot be updated (only new\n   elements can be created in the table).\n \n   As we mentioned, the library contains two types of media, books and\n   DVDs. Each of those has a title, an author. However, a book also has\n@@ -387,15 +387,15 @@\n   declare one abstract table (media) which contains the common fields,\n   and two tables to represent the types of media.\n \n   As we mentioned, a media can be borrowed by at most one customer,\n   but a customer can have multiple media at any point in time. This is\n   called a **one-to-many** relationship. In SQL, this is in general\n   described through the use of a foreign key that goes from the table\n-  on the \u201cmany\u201d side. In this example, we therefore have a foreign key\n+  on the \"many\" side. In this example, we therefore have a foreign key\n   from media to customers. We also provide a name for the reverse\n   relationship, which will become clearer when we describe the ORM\n   interface.\n \n   Here are the declarations:\n \n      | ABSTRACT TABLE | media               | media || The contents of the library |\n@@ -415,15 +415,15 @@\n   \"dbschema.txt\".\n \n \n 1.4. The gnatcoll_db2ada tool\n =============================\n \n As stated in the introduction, one of the goals of this library is to\n-make sure the application\u2019s code follows changes in the schema of your\n+make sure the application's code follows changes in the schema of your\n database.\n \n To reach this goal, an external tool, \"gnatcoll_db2ada\" is provided\n with GNATColl, and should be spawned as the first step of the build\n process, or at least whenever the database schema changes. It\n generates an Ada package (*Database* by default) which reflects the\n current schema of the database.\n@@ -437,15 +437,15 @@\n    These parameters specify the connection parameters for the\n    database. To find out the schema, \"gnatcoll_db2ada\" can connect to\n    an existing database (Database schema). The user does not need to\n    have write permission on the database, since all queries are read-\n    only.\n \n *-dbmodel file*\n-   This parameter can replace the above *-dbname*,\u2026 It specifies the\n+   This parameter can replace the above *-dbname*,... It specifies the\n    name of a text file that contains the description of the database,\n    therefore avoiding the need for already having a database up-and-\n    running to generate the Ada interface.\n \n    The format of this text file was described in the previous section.\n \n    This switch is not compatible with *-enum* and *-vars* that really\n@@ -476,21 +476,21 @@\n    application, without requiring access to the external files that\n    define the schema and the initial data.\n \n *-enum table,id,name,prefix,base*\n    This parameter can be repeated several times if needed. It\n    identifies one of the special tables of the database that acts as\n    an enumeration type. It is indeed often the case that one or more\n-   tables in the database have a role similar to Ada\u2019s enumeration\n+   tables in the database have a role similar to Ada's enumeration\n    types, i.e. contains a list of values for information like the list\n-   of possible priorities, a list of countries,\u2026 Such lists are only\n+   of possible priorities, a list of countries,... Such lists are only\n    manipulated by the maintainer of the database, not interactively,\n-   and some of their values have impact on the application\u2019s code (for\n+   and some of their values have impact on the application's code (for\n    instance, if a ticket has an urgent priority, we need to send a\n-   reminder every day \u2013 but the application needs to know what an\n+   reminder every day -- but the application needs to know what an\n    urgent priority is). In such a case, it is convenient to generate\n    these values as constants in the generated package. The output will\n    be similar to:\n \n       subtype Priority_Id is Integer;\n       Priority_High   : constant Priority_Id := 3;\n       Priority_Medium : constant Priority_Id := 2;\n@@ -513,15 +513,15 @@\n       -enum ticket_priorities,Priority,Name,Priority,Integer\n \n    First word in the parameter is the table name where the data to\n    generate constants is stored. Second word is the field name in the\n    table where the Ada constant value is stored. The third word is the\n    field where the last part the Ada constant name is stored. The\n    forth word is the prefix to add in front of the third word field\n-   value to generate the Ada constant\u2019s name. The last optional\n+   value to generate the Ada constant's name. The last optional\n    parameter should be either *Integer* (default) or *String*, which\n    influences the way how the Ada constant value is going to be\n    generated (surrounded or not by quotes).\n \n *-enum-image*\n    If specified in addition to the *-enum* switch, then a function is\n    generated for each *Integer*-valued enum that converts numeric\n@@ -560,15 +560,15 @@\n \n    which generates:\n \n       No_Assigne_Id : constant := 0;\n       --  help\n \n    The application should use this constant rather than some hard-\n-   coded string *\u201cunassigned\u201d* or a named constant with the same\n+   coded string *\"unassigned\"* or a named constant with the same\n    value. The reason is that presumably the login will be made visible\n    somewhere to the user, and we could decide to change it (or\n    translate it to another language). In such a case, the application\n    would break. On the other hand, using the constant *0* which we\n    just extracted will remain valid, whatever the actual text we\n    display for the user.\n \n@@ -672,32 +672,32 @@\n a database (or at least its schema). This operation can also be\n performed directly from your Ada code by using the services provided\n in the *GNATCOLL.SQL.Inspect* package. In particular, there are\n services for reading the schema of a database either from a file or\n from a live database, just as *gnatcoll_db2ada* does.\n \n This results in a structure in memory that you can use to find out\n-which are the tables, what are their fields, their primary keys,\u2026\n+which are the tables, what are their fields, their primary keys,...\n \n It is also possible to dump this schema to a text file (with the same\n format as expected by *-dbmodel*), or more interestingly to output the\n SQL statements that are needed to create the tables in a database. In\n the case of Sqlite, creating a table will also create the database\n-file if it doesn\u2019t exist yet, so no special rights are needed.\n+file if it doesn't exist yet, so no special rights are needed.\n \n This input/output mechanism is implemented through an abstract\n *Schema_IO* tagged type, with various concrete implementations (either\n *File_Schema_IO* to read or write from/to a file, or *DB_Schema_IO* to\n read or write from/to a database).\n \n See the specs for more detail on these subprograms.\n \n \n-1.4.3. Back to the library example\u2026\n------------------------------------\n+1.4.3. Back to the library example...\n+-------------------------------------\n \n In the previous section, we have described our database schema in a\n text file. We will now perform two operations:\n \n * Create an empty database\n \n   This should of course only be done once, not every time you run your\n@@ -760,15 +760,15 @@\n parameters. This is done via a\n *GNATCOLL.SQL.Exec.Database_Description* object. The creation of this\n object depends on the specific DBMS you are connecting to (and this is\n the only part of your code that needs to know about the specific\n system). The packages *GNATCOLL.SQL.Postgres* and\n *GNATCOLL.SQL.Sqlite* contain a *Setup* function, whose parameters\n depend on the DBMS. They provide full documentation for their\n-parameters. Let\u2019s take a simple example from sqlite:\n+parameters. Let's take a simple example from sqlite:\n \n    with GNATCOLL.SQL.Sqlite;   -- or Postgres\n    declare\n       DB_Descr : GNATCOLL.SQL.Exec.Database_Description;\n    begin\n       DB_Descr := GNATCOLL.SQL.Sqlite.Setup (\"dbname.db\");\n    end\n@@ -839,15 +839,15 @@\n critical will appear if you do not close, though, because the\n transactions to the DBMS server are saved every time you call *Commit*\n in any case. So the code would end with:\n \n    Free (DB);  --  for all connections you have opened\n    Free (DB_Descr);\n \n-At this point, there still hasn\u2019t been any connection to the DBMS.\n+At this point, there still hasn't been any connection to the DBMS.\n This will be done the first time a query is executed. If for some\n reason the connection to the DBMS server is lost, GNATColl will\n automatically attempt to reconnect a number of times before it gives\n up. This might break if there was an ongoing SQL transaction, but\n simplifies your code since you do not have to handle reconnection when\n there was a network failure, for instance.\n \n@@ -881,28 +881,28 @@\n   interface when the DBMS provides one for instance), or via a command\n   line tool (*psql* for PostgreSQL or *sqlite3* for Sqlite), and start\n   inserting data manually. This shows one of the nice aspects of using\n   a standard DBMS for your application: you can alter the database\n   (for instance to do minor fixes in the data) with a lot of external\n   tools that were developed specifically for that purpose and that\n   provide a nice interface. However, this is also tedious and error\n-  prone, and can\u2019t be repeat easily every time we recreate the\n+  prone, and can't be repeat easily every time we recreate the\n   database (for instance before running automatic tests).\n \n * Using *GNATCOLL.SQL.EXEC*\n \n   As we will describe later, GNATColl contains all the required\n   machinery for altering the contents of the database and creating new\n   objects. Using *GNATCOLL.SQL.ORM* this can also be done at a high-\n   level and completely hide SQL.\n \n * Loading a data file\n \n   A lot of frameworks call such a file that contains initial data a\n-  \u201cfixture\u201d. We will use this technique as an example. At the Ada\n+  \"fixture\". We will use this technique as an example. At the Ada\n   level, this is a simple call to *GNATCOLL.SQL.Inspect.Load_Data*.\n   The package contains a lot more than just this subprogram (The\n   gnatcoll_db2ada tool):\n \n      declare\n         File : GNATCOLL.VFS.Virtual_File := Create (\"fixture.txt\");\n         DB : Database_Connection;  --  created earlier\n@@ -914,15 +914,15 @@\n   The format of this file is described just below.\n \n As we mentioned, GNATColl can load data from a file. The format of\n this file is similar to the one that describes the database schema. It\n is a set of ASCII tables, each of which describes the data that should\n go in a table (it is valid to duplicate tables). Each block starts\n with two lines: The first one has two mandatory columns, the first of\n-which contains the text \u201cTABLE\u201d, and the second contains the name of\n+which contains the text \"TABLE\", and the second contains the name of\n the table you want to fill. The second line should contain as many\n columns as there are fields you want to set. Not all the fields of the\n table need to have a corresponding column if you want to set their\n contents to NULL (provided, of course, that your schema allows it).\n For instance, we could add data for our library example as such:\n \n    | TABLE | customers |        |\n@@ -953,15 +953,15 @@\n    | title        | author    | region | borrowed_by(&last) |\n    |--------------+-----------+--------+--------------------|\n    | The Birds    | Hitchcock |      1 | &Smith             |\n    | The Dictator | Chaplin   |      3 | &Dupont            |\n \n Here, the title of the column indicates that any value in this column\n might be a reference to the *customers.last* value. Values which start\n-with an ampersand (\u201d&\u201d) will therefore be looked up in\n+with an ampersand (\"&\") will therefore be looked up in\n *customers.last*, and the *id* of the corresponding customer will be\n inserted in the *dvds* table. It would still be valid to use directly\n customer ids instead of references, this is just an extra flexibility\n that the references give you to make your fixtures more readable.\n \n However, if we are using such references we need to provide the\n database schema to *Load_Data* so that it can write the proper\n@@ -1008,26 +1008,26 @@\n          From   => Ticket_Priorities,\n          Where  => Ticket_Priorities.Name /= \"low\",\n          Group_By => Ticket_Priorities.Category);\n    end;\n \n The above example will return, for each type of priority (internal or\n customer) the highest possible value. The interest of this query is\n-left to the user\u2026\n+left to the user...\n \n This is very similar to an actual SQL query. Field and table names\n come from the package that was automatically generated by the\n *gnatcoll_db2ada* tool, and therefore we know that our query is only\n referencing existing fields. The syntactic correctness is ensured by\n standard Ada rules. The *SQL_Select* accepts several parameters\n corresponding to the usual SQL attributes like *GROUP BY*, *HAVING*,\n *ORDER BY* and *LIMIT*.\n \n The *From* parameter could be a list of tables if we need to join them\n-in some ways. Such a list is created with the overridden *\u201c&\u201d*\n+in some ways. Such a list is created with the overridden *\"&\"*\n operator, just as for fields which you can see in the above example.\n GNATColl also provides a *Left_Join* function to join two tables when\n the second might have no matching field (see the SQL documentation).\n \n Similar functions exist for *SQL_Insert*, *SQL_Update* and\n *SQL_Delete*. Each of those is extensively documented in the\n \"gnatcoll-sql.ads\" file.\n@@ -1074,16 +1074,16 @@\n those queries.\n \n There is another case where GNATColl makes it somewhat easier to write\n the queries, and that is to handle joins between tables. If your\n schema was build with foreign keys, GNATColl can take advantage of\n those.\n \n-Going back to our library example, let\u2019s assume we want to find out\n-all the books that were borrowed by the user \u201cSmith\u201d. We need to\n+Going back to our library example, let's assume we want to find out\n+all the books that were borrowed by the user \"Smith\". We need to\n involve two tables (*Books* and *Customers*), and provide a join\n between them so that the DBMS knows how to associate the rows from one\n with the rows from the other. Here is a first example for such a\n query:\n \n    Q := SQL_Select\n       (Fields => Books.Title & Books.Pages,\n@@ -1098,15 +1098,15 @@\n       (Fields => Books.Title & Books.Pages,\n        Where  => Books.Borrowed_By = Customers.Id\n           and Customers.Last = \"Smith\");\n \n There is one more things we can do to simplify the query and make it\n more solid if the schema of the database changes. For instance, when a\n table has a primary key made up of several fields, we need to make\n-sure we always have an \u201c=\u201d statement in the WHERE clause for all these\n+sure we always have an \"=\" statement in the WHERE clause for all these\n fields between the two tables. In our example above, we could at some\n point modify the schema so that the primary key for *customers* is\n multiple (this is unlikely in this example of course). To avoid this\n potential problems and make the query somewhat easier to read, we can\n take advantage of the *FK* subprograms generated by *gnatcoll_db2ada*.\n Using the Ada05 dotted notation for the call, we can thus write:\n \n@@ -1147,15 +1147,15 @@\n variable *R*.\n \n If for some reason the connection to the database is no longer valid\n (a transient network problem for instance), GNATColl will attempt to\n reconnect and re-execute your query transparently, so that your\n application does not need to handle this case.\n \n-We\u2019ll describe later (Getting results) how to analyze the result of\n+We'll describe later (Getting results) how to analyze the result of\n the query.\n \n Some versions of *Fetch* have an extra parameter *Use_Cache*, set to\n *False* by default. If this parameter is true, and the exact same\n query has already been executed before, its result will be reused\n without even contacting the database server. The cache is\n automatically invalidated every hour in any case. This cache is mostly\n@@ -1244,15 +1244,15 @@\n        SQL_Select\n           (Fields => Data.Id & Data.Name\n            From   => Data,\n            Where  => Data.Id = Integer_Param (1));\n \n GNATColl provides a number of functions (one per type of field) to\n indicate that the value is currently unbound. *Integer_Param*,\n-*Text_Param*, *Boolean_Param*,\u2026 All take a single argument, which is\n+*Text_Param*, *Boolean_Param*,... All take a single argument, which is\n the index of the corresponding parameter. A query might need several\n parameters, and each should have a different index. On the other hand,\n the same parameter could be used in several places in the query.\n \n Although the query above could be executed as is by providing the\n values for the parameters, it is more efficient, as we mentioned at\n the beginning, to compile it on the server. In theory, this\n@@ -1281,40 +1281,40 @@\n   reference counted type, that will automatically free the memory on\n   the server when it goes out of scope.\n \n * Here, we prepared the statement on the server. If we had specified\n   *On_Server => False*, we would still have sped things up, since Q\n   would be converted to a string that can be sent to the DBMS, and\n   from then on reused that string (note that this conversion is\n-  specific to each DBMS, since they don\u2019t always represent things the\n+  specific to each DBMS, since they don't always represent things the\n   same way, in particular parameters, as we have seen above). Thus\n   every time you use P you save the time of converting from the\n   GNATColl tree representation of the query to a string for the DBMS.\n \n Now that we have a prepared statement, we can simply execute it. If\n the statement does not require parameters, the usual *Fetch* and\n *Execute* subprograms have versions that work exactly the same with\n prepared statements. They also accept a *Params* parameter that\n-contains the parameter to pass to the server. A number of *\u201c+\u201d*\n+contains the parameter to pass to the server. A number of *\"+\"*\n operators are provided to create those parameters:\n \n    declare\n       F : Forward_Cursor;\n    begin\n       F.Fetch (DB, P, Params => (1 => +2));\n       F.Fetch (DB, P, Params => (1 => +3));\n    end;\n \n-Note that for string parameters, the *\u201c+\u201d* operator takes an access to\n+Note that for string parameters, the *\"+\"* operator takes an access to\n a string. This is for efficiency, to avoid allocating memory and\n copying the string, and is safe because the parameters are only needed\n while *Fetch* executes (even for a *Forward_Cursor*.\n \n Back to our library example. We showed earlier how to write a query\n-that retrieves the books borrowed by customer \u201cSmith\u201d. We will now\n+that retrieves the books borrowed by customer \"Smith\". We will now\n make this query more general: given a customer name, return all the\n books he has borrowed. Since we expect to use this often, we will\n prepare it on the server (in real life, this query is of little\n interest since the customer name is not unique, we would instead use a\n query that takes the id of the customer). In general we would create a\n global variable with:\n \n@@ -1395,15 +1395,15 @@\n previously except by executing the query again. This is in fact only\n true if you use a *Forward_Cursor* to fetch the results.\n \n But GNATColl provides another notion, a *Direct_Cursor*. In this case,\n it fetches all the rows in memory when the query executes (thus it\n needs to allocate more memory to save every thing, which can be costly\n if the query is big). This behavior is supported natively by\n-*PostgreSQL*, but doesn\u2019t exist with *sqlite*, so GNATColl will\n+*PostgreSQL*, but doesn't exist with *sqlite*, so GNATColl will\n simulate it as efficiently as possible. But it will almost always be\n faster to use a *Forward_Cursor*.\n \n In exchange for this extra memory overhead, you can now traverse the\n list of results in both directions, as well as access a specific row\n directly. It is also possible to know the number of rows that matched\n (something hard to do with a *Forward_Cursor* since you would need to\n@@ -1508,20 +1508,20 @@\n database interface uses this module to log the queries that are sent\n to the server.\n \n If you activate traces in your application, the user can then activate\n one of the following trace handles to get more information on the\n exchange that exists between the database and the application. As we\n saw before, the output of these traces can be sent to the standard\n-output, a file, the system logs,\u2026\n+output, a file, the system logs,...\n \n The following handles are provided:\n \n * SQL.ERROR This stream is activated by default. Any error returned by\n-  the database (connection issues, failed transactions,\u2026) will be\n+  the database (connection issues, failed transactions,...) will be\n   logged on this stream\n \n * SQL This stream logs all queries that are not SELECT queries, i.e.\n   mostly all queries that actually modify the database\n \n * SQL.SELECT This stream logs all select queries. It is separated from\n   SQL because very often you will be mostly interested in the queries\n@@ -1535,15 +1535,15 @@\n    procedure Main is\n    begin\n       GNATCOLL.Traces.Parse_Config_File (\".gnatdebug\");\n       ... --  code as before\n       GNATCOLL.Traces.Finalize;  --  reclaim memory\n \n and then create a .gnatdebug in the directory from which we launch our\n-executable. This file would contain a single line containing \u201c+\u201d to\n+executable. This file would contain a single line containing \"+\" to\n activate all log streams, or the following to activate only the subset\n of fields related to SQL:\n \n    SQL=yes\n    SQL.SELECT=yes\n    SQL.LITE=yes\n \n@@ -1575,15 +1575,15 @@\n    function Do_Query (DB, ...) return My_Cursor;\n \n The idea is that you create a function that does the query for you\n (based on some parameters that are not shown here), and then returns a\n cursor over the resulting set of rows. For each row, you can use the\n *Element* function to get an Ada record for easier manipulation.\n \n-Let\u2019s first see how these types would be used in practice:\n+Let's first see how these types would be used in practice:\n \n    declare\n      C : My_Cursor := Do_Query (DB, ...);\n    begin\n      while Has_Row (C) loop\n         Put_Line (\"Id = \" & Element (C).Id);\n         Next (C);\n@@ -1666,15 +1666,15 @@\n objects stored in a database, using a common paradigm called an\n object-relational mapping. Such mappings exist for most programming\n languages. In the design of GNATColl, we were especially inspired by\n the python interface in *django* and *sqlalchemy*, although the last\n two rely on dynamic run time introspection and GNATColl relies on code\n generation instead.\n \n-This API is still compatible with *GNATCOLL.SQL*. In fact, we\u2019ll show\n+This API is still compatible with *GNATCOLL.SQL*. In fact, we'll show\n below cases where the two are mixed. It can also be mixed with\n *GNATCOLL.SQL.Exec*, although this might be more risky. Communication\n with the DBMS is mostly transparent in the ORM, and it uses various\n caches to optimize things and make sure that if you modify an element\n the next query(ies) will also return it. If you use\n *GNATCOLL.SQL.Exec* directly you are bypassing this cache so you risk\n getting inconsistent results in some cases.\n@@ -1693,15 +1693,15 @@\n class has foreign keys to other tables. So we remove the *borrowed_by*\n field from the *Media* table, and change the *books* table to be:\n \n    | TABLE (media) | books                        | book |     | The books in the library |\n    | pages         | INTEGER                      |      | 100 |                          |\n    | borrowed_by   | FK customers(borrowed_books) | NULL |     | Who borrowed the media   |\n \n-Let\u2019s thus start by generating this code. We can replace the command\n+Let's thus start by generating this code. We can replace the command\n we ran earlier (with the *-api* switch) with one that will also\n generate the ORM API:\n \n    gnatcoll_db2ada -dbmode dbschema.txt -api Database -orm ORM\n \n The ORM provides a pool of database connections through the package\n *GNATCOLL.SQL.Sessions*. A session therefore acts as a wrapper around\n@@ -1720,39 +1720,39 @@\n \n The first parameter is the same *Database_Description* we saw earlier\n (Connecting to the database), but it will be freed automatically by\n the sessions package, so you should not free it yourself.\n \n Once configure, we can now request a session. Through a session, we\n can perform queries on the database, make objects persistent, write\n-the changes back to the database,\u2026. We configured the session pool to\n-have at most 2 sessions. The first time we call *Get_New_Session*, a\n-new session will be created in the pool and marked as busy. While you\n-have a reference to it in your code (generally as a local variable),\n-the session belongs to this part of the code. When the session is no\n-longer in scope, it is automatically released to the pool to be reused\n-for the next call to *Get_New_Session*. If you call *Get_New_Session*\n-a second time while some part of your code holds a session (for\n-instance in a different task), a new session will be created. But if\n-you do that a third time while the other two are busy, the call to\n-*Get_New_Session* is blocking until one of the two sessions is\n-released to the pool.\n+the changes back to the database,.... We configured the session pool\n+to have at most 2 sessions. The first time we call *Get_New_Session*,\n+a new session will be created in the pool and marked as busy. While\n+you have a reference to it in your code (generally as a local\n+variable), the session belongs to this part of the code. When the\n+session is no longer in scope, it is automatically released to the\n+pool to be reused for the next call to *Get_New_Session*. If you call\n+*Get_New_Session* a second time while some part of your code holds a\n+session (for instance in a different task), a new session will be\n+created. But if you do that a third time while the other two are busy,\n+the call to *Get_New_Session* is blocking until one of the two\n+sessions is released to the pool.\n \n This technique ensures optimal use of the resources: we avoid creating\n a new session every time (with the performance cost of connecting to\n the database), but also avoid creating an unlimited number of sessions\n which could saturate the server. Since the sessions are created lazily\n the first time they are needed, you can also configure the package\n with a large number of sessions with a limited cost.\n \n-Let\u2019s then take a new session in our code:\n+Let's then take a new session in our code:\n \n    Session : constant Session_Type := Get_New_Session;\n \n-and let\u2019s immediately write our first simple query. A customer comes\n+and let's immediately write our first simple query. A customer comes\n at the library, handles his card and we see his id (1). We need to\n look up in the database to find out who he is. Fortunately, there is\n no SQL to write for this:\n \n    C : ORM.Detached_Customer'Class := Get_Customer (Session, Id => 1);\n \n The call to *Get_Customer* performs a SQL query transparently, using\n@@ -1772,15 +1772,15 @@\n   your own cursors). This object is no longer valid as soon as the\n   cursor moves to the next row (in the currently implementation, the\n   object will describe the next row, but it is best not to rely on\n   this). As a benefit, this object is light weight and does not make a\n   copy of the value of the fields, only reference the memory that is\n   already allocated for the cursor.\n \n-  This object redefines the equality operator (\u201c=\u201d) to compare the\n+  This object redefines the equality operator (\"=\") to compare the\n   primary key fields to get expected results.\n \n * *Detached_Customer*\n \n   A detached object is very similar to the *Customer* object, but it\n   will remain valid even if the cursor moves or is destroyed. In fact,\n   the object has made a copy of the value for all of its fields. This\n@@ -1813,15 +1813,15 @@\n \n * *Customers_Managers*\n \n   This type is the base type to perform queries on the DBMS. A manager\n   provides a number of primitive operations which end up creating a\n   SQL query operation in the background, without making that explicit.\n \n-  Let\u2019s first write a query that returns all books in the database:\n+  Let's first write a query that returns all books in the database:\n \n      declare\n         M : Books_Managers := All_Books;\n         BL : Book_List := M.Get (Session);\n         B : Book;\n      begin\n         while BL.Has_Row loop\n@@ -1831,15 +1831,15 @@\n            BL.Next;\n         end loop;\n      end;\n \n   The manager *M* corresponds to a query that returns all the books in\n   the database. The second line then executes the query on the\n   database, and returns a list of books. We then traverse the list.\n-  Note how we access the book\u2019s title by calling a function, rather\n+  Note how we access the book's title by calling a function, rather\n   than by the index of a field as we did with *GNATCOLL.SQL.Exec* with\n   Value(B, 0). The code is much less fragile this way.\n \n   The line that calls *Borrowed_By* will execute an additional SQL\n   query for each book. This might be inefficient if there is a large\n   number of books. We will show later how this can be optimized.\n \n@@ -1855,15 +1855,15 @@\n     As seen in the example above, these are the two functions that\n     execute the query on the database, and returns a list of objects\n     (respectively a *Customer_List* and a *Direct_Customer_List*).\n \n   * *Distinct*\n \n     Returns a copy of the manager that does not return twice a row\n-    with the same data (in SQL, this is the \u201cDISTINCT\u201d operator)\n+    with the same data (in SQL, this is the \"DISTINCT\" operator)\n \n   * *Limit* (Count : Natural; From : Natural := 0)\n \n     Returns a copy of the manager that returns a subset of the\n     results, for instance the first *Count* ones.\n \n   * *Order_By* (By : SQL_Field_List)\n@@ -1893,15 +1893,15 @@\n \n        M : Books_Managers := All_Books.Filter (Condition => Books.Pages < 50);\n \n     More complex conditions are possible, involving other tables.\n     Currently, the ORM does not have a very user-friendly interface\n     for those, but you can always do this by falling back partially to\n     SQL. For instance, if we want to retrieve all the books borrowed\n-    by user \u201cSmith\u201d, we need to involve the *Customers* table, and\n+    by user \"Smith\", we need to involve the *Customers* table, and\n     thus make a join with the *Books* table. In the future, we intend\n     to make this join automatic, but for now you will need to write:\n \n        M : Books_Managers := All_Books.Filter\n          (Books.FK (Customers)\n           and Customers.Last = \"Smith\");\n \n@@ -1934,15 +1934,15 @@\n     will result in a query. So if you pass 2 for *Depth* the data for\n     book, customers and addresses will be retrieved.\n \n     The second parameter related to efficiency. When a foreign key was\n     mentioned as *NOT NULL* in the schema, we know it is always\n     pointing to an existing object in another table. *Select_Related*\n     will always retrieve such objects. If, however, the foreign key\n-    can be null, i.e. there isn\u2019t necessarily a corresponding object\n+    can be null, i.e. there isn't necessarily a corresponding object\n     in the other table, the SQL query needs to use a *LEFT JOIN*,\n     which is less efficient.  By default, GNATColl will not retrieve\n     such fields unless *Follow_Left_Join* was set to True.\n \n     In our example, a book is not necessarily borrowed by a customer,\n     so we need to follow the left joins:\n \n@@ -1974,19 +1974,19 @@\n    --    WHERE books.borrowed_by=1\n \n *Borrowed_Books* is a function that was generated because there was a\n *reverse_name*. It returns a *Books_Managers*, so we could in fact\n further filter the list of borrowed books with the same primitive\n operations we just saw. As you can see, the resulting SQL is optimal.\n \n-Let\u2019s optimize further the initial query. We have hard-coded the\n+Let's optimize further the initial query. We have hard-coded the\n customer name, but in fact we could be using the same subprograms we\n were using for prepared statements (Prepared queries), and even\n prepare the query on the server for maximum efficiency. Since our\n-application is likely to use this query a lot, let\u2019s create a global\n+application is likely to use this query a lot, let's create a global\n variable:\n \n    M : constant Books_Managers := All_Books.Filter\n      (Books.FK (Customers)\n       and Customers.Id = Integer_Param (1))\n      .Select_Related (1, Follow_Left_Join => True);\n \n@@ -2006,16 +2006,16 @@\n 1.15. Modifying objects in the ORM\n ==================================\n \n The ORM is much more than writing queries. Once the objects are\n persistent, they can also be simplify modified, and they will be saved\n in the database transparently.\n \n-Let\u2019s start with a simple example. In the previous section, we\n-retrieve an object *C* representing a customer. Let\u2019s change his name,\n+Let's start with a simple example. In the previous section, we\n+retrieve an object *C* representing a customer. Let's change his name,\n and make sure the change is in the database:\n \n    C := Get_Customer (Session, 1);\n    C.Set_Last (\"Smith\");\n    C.Set_First (\"Andrew\");\n    Session.Commit;\n \n@@ -2083,15 +2083,15 @@\n       CL.Next;\n    end loop;\n \n The above example uses *CL.Element*, which is a light-weight\n *Customer* object. Such objects will only see the in-memory changes if\n you have set *Flush_Before_Query* to true when you configured the\n sessions in the call to *GNATCOLL.SQL.Sessions.Setup*. Otherwise, it\n-will always return what\u2019s really in the database.\n+will always return what's really in the database.\n \n If the example was using *Detached_Customer* object (by calling\n *CL.Element.Detach* for instance) then GNATColl looks up in its\n internal cache and returns the cached element when possible. This is a\n subtlety, but this is because an *Customer* only exists as long as its\n cursor, and therefore cannot be cached in the session. In practice,\n the *Flush_Before_Query* should almost always be true and there will\n@@ -2104,34 +2104,34 @@\n Often, a database table is used to contain objects that are\n semantically of a different kind. In this section, we will take a\n slightly different example from the library. We no longer store the\n books and the dvds in separate tables. Instead, we have one single\n *media* table which contains the title and the author, as well as a\n new field *kind* which is either 0 for a book or 1 for a dvd.\n \n-Let\u2019s now look at all the media borrowed by a customer:\n+Let's now look at all the media borrowed by a customer:\n \n    C : constant Customer'Class := Get_Customer (Session, Id => 1);\n    ML : Media_List := C.Borrowed_Media.Get (Session);\n \n    while ML.Has_Row loop\n       case ML.Element.Kind is\n          when 0 =>\n             Put_Line (\"A book \" & ML.Element.Title);\n          when 1 =>\n             Put_Line (\"A dvd \" & ML.Element.Title);\n       end case;\n       ML.Next;\n    end loop;\n \n-This code works, but requires a case statement. Now, let\u2019s imagine the\n+This code works, but requires a case statement. Now, let's imagine the\n check out procedure is different for a book and a DVD (for the latter\n we need to check that the disk is indeed in the box). We would have\n two subprograms *Checkout_Book* and *Checkout_DVD* and call them from\n-the case. This isn\u2019t object-oriented programming.\n+the case. This isn't object-oriented programming.\n \n Instead, we will declare two new types:\n \n    type My_Media is abstract new ORM.Detached_Media with private;\n    procedure Checkout (Self : My_Media) is abstract;\n \n    type Detached_Book is new My_Media with private;\n@@ -2145,17 +2145,17 @@\n we would also need to override *Get* so that it returns our new list.\n This is tedious.\n \n We will instead use an element factory in the session. This is a\n function that gets a row of a table (in the form of a *Customer*), and\n returns the appropriate type to use when the element is detached (by\n default, the detached type corresponding to a *Customer* is a\n-*Detached_Customer*, and that\u2019s what we want to change).\n+*Detached_Customer*, and that's what we want to change).\n \n-So let\u2019s create such a factory:\n+So let's create such a factory:\n \n    function Media_Factory\n       (From    : Base_Element'Class;\n        Default : Detached_Element'Class) return Detached_Element'Class\n    is\n    begin\n       if From in Media'Class then\n", "details": [{"source1": "encoding", "source2": "encoding", "unified_diff": "@@ -1 +1 @@\n-utf-8\n+us-ascii\n"}]}]}]}]}]}]}