{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.h0esQTE8/b1/libgnatcoll-db_25.0.0-2_amd64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.h0esQTE8/b2/libgnatcoll-db_25.0.0-2_amd64.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,11 +1,11 @@\n \n  51bd56c8a20e0f05eefa2ef3cd931747 392600 debug optional libgnatcoll-db-bin-dbgsym_25.0.0-2_amd64.deb\n  9a2ebc3a6b5a174909ddf089b9df0f03 214724 devel optional libgnatcoll-db-bin_25.0.0-2_amd64.deb\n- e50639565f99f818c7d3af4ff74d86ce 522532 doc optional libgnatcoll-db-doc_25.0.0-2_all.deb\n+ 1663ff73c3634d9583a1de7f0fb6ccc9 523048 doc optional libgnatcoll-db-doc_25.0.0-2_all.deb\n  86afa36ebe0f3bbba03b2773a0544b79 164828 libdevel optional libgnatcoll-postgres-dev_25.0.0-2_amd64.deb\n  07e268f0b5990e09406eb9c65c38a678 223432 debug optional libgnatcoll-postgres2-dbgsym_25.0.0-2_amd64.deb\n  12e81d6ba47e17eea06948d0d89fa6b8 145508 libs optional libgnatcoll-postgres2_25.0.0-2_amd64.deb\n  5de2d462e2fdb1d0658555addb9e4931 1244576 libdevel optional libgnatcoll-sql-dev_25.0.0-2_amd64.deb\n  4d01ded5e153f0ea4d3a7daec3faaf3f 2019516 debug optional libgnatcoll-sql4-dbgsym_25.0.0-2_amd64.deb\n  2d79d94007ca5d26dcdc7bff46067d37 1095144 libs optional libgnatcoll-sql4_25.0.0-2_amd64.deb\n  9ab79852341b37673e11e4c167cda6da 73988 libdevel optional libgnatcoll-sqlite-dev_25.0.0-2_amd64.deb\n"}, {"source1": "libgnatcoll-db-doc_25.0.0-2_all.deb", "source2": "libgnatcoll-db-doc_25.0.0-2_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 2025-03-20 08:42:03.000000 debian-binary\n -rw-r--r--   0        0        0     1784 2025-03-20 08:42:03.000000 control.tar.xz\n--rw-r--r--   0        0        0   520556 2025-03-20 08:42:03.000000 data.tar.xz\n+-rw-r--r--   0        0        0   521072 2025-03-20 08:42:03.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": "@@ -11,15 +11,15 @@\n -rw-r--r--   0 root         (0) root         (0)     1321 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/examples/library/dbschema.txt\n -rw-r--r--   0 root         (0) root         (0)      463 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/examples/library/default.gpr\n -rw-r--r--   0 root         (0) root         (0)      812 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/examples/library/fixture.txt\n -rwxr-xr-x   0 root         (0) root         (0)      124 2025-03-20 08:42:03.000000 ./usr/share/doc/libgnatcoll-db-doc/examples/library/generate.sh\n drwxr-xr-x   0 root         (0) root         (0)        0 2025-03-20 08:42:03.000000 ./usr/share/doc/libgnatcoll-db-doc/examples/library/generated/\n drwxr-xr-x   0 root         (0) root         (0)        0 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/examples/library/src/\n -rw-r--r--   0 root         (0) root         (0)     7115 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/examples/library/src/library.adb\n--rw-r--r--   0 root         (0) root         (0)   336008 2025-03-20 08:42:03.000000 ./usr/share/doc/libgnatcoll-db-doc/gnatcoll-db.pdf.gz\n+-rw-r--r--   0 root         (0) root         (0)   336497 2025-03-20 08:42:03.000000 ./usr/share/doc/libgnatcoll-db-doc/gnatcoll-db.pdf.gz\n drwxr-xr-x   0 root         (0) root         (0)        0 2025-03-20 08:42:03.000000 ./usr/share/doc/libgnatcoll-db-doc/html/\n drwxr-xr-x   0 root         (0) root         (0)        0 2025-03-20 08:42:03.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_images/\n -rw-r--r--   0 root         (0) root         (0)     1447 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_images/important.png\n -rw-r--r--   0 root         (0) root         (0)     2247 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_images/note.png\n -rw-r--r--   0 root         (0) root         (0)     2143 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_images/tip.png\n drwxr-xr-x   0 root         (0) root         (0)        0 2025-03-20 08:42:03.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_sources/\n -rw-r--r--   0 root         (0) root         (0)      413 2023-11-06 10:21:17.000000 ./usr/share/doc/libgnatcoll-db-doc/html/_sources/index.rst.txt\n"}, {"source1": "./usr/share/doc/libgnatcoll-db-doc/gnatcoll-db.pdf.gz", "source2": "./usr/share/doc/libgnatcoll-db-doc/gnatcoll-db.pdf.gz", "unified_diff": null, "details": [{"source1": "gnatcoll-db.pdf", "source2": "gnatcoll-db.pdf", "unified_diff": null, "details": [{"source1": "pdftotext {} -", "source2": "pdftotext {} -", "unified_diff": "@@ -16,15 +16,15 @@\n 1.3 Database schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.4 The gnatcoll_db2ada tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.4.1\n Default output of gnatcoll_db2ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.4.2\n database introspection in Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.4.3\n-Back to the library example... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n+Back to the library example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.5 Connecting to the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.6 Loading initial data in the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.7 Writing queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.8 Executing queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.9 Prepared queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.10 Getting results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n 1.11 Creating your own SQL types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n@@ -102,25 +102,25 @@\n two systems. For instance, development could be done using a local sqlite DBMS, and then deployed (after\n testing, of course!) on a PostgreSQL system.\n The code in GNATColl is such that adding support for a new DBMS should be relatively easy.\n \u2022 A place where an application stores its data. The term database in this document refers to this meaning. In a\n relational database, this place is organized into tables, each of which contains a number of fields. A row in a\n table represents one object. The set of tables and their fields is called the schema of the database.\n Traditionally, writing the SQL queries is done inline: special markers are inserted into your code to delimit sections\n-that contain SQL code (as opposed to Ada code), and these are then preprocessed to generate actual code. This isn't\n+that contain SQL code (as opposed to Ada code), and these are then preprocessed to generate actual code. This isn\u2019t\n the approach chosen in GNATColl: there are several drawbacks, in particular your code is no longer Ada and various\n tools will choke on it.\n The other usual approach is to write the queries as strings, which are passed, via a DBMS-specific API, to the DBMS\n server. This approach is very fragile:\n \u2022 The string might not contain well-formed SQL. This will unfortunately only be detected at run time when the\n DBMS complains.\n \u2022 This is not type safe. You might be comparing a text field with an integer, for instance. In some cases, the DBMS\n-will accept that (sqlite for instance), but in some other cases it won't (PostgreSQL). The result might then either\n+will accept that (sqlite for instance), but in some other cases it won\u2019t (PostgreSQL). The result might then either\n raise an error, or return an empty list.\n-\u2022 There is a risk of SQL injection. Assuming the string is constructed dynamically (using Ada's & operator), it\n+\u2022 There is a risk of SQL injection. Assuming the string is constructed dynamically (using Ada\u2019s & operator), it\n might be easy for a user to pass a string that breaks the query, and even destroys things in the database.\n \u2022 As discussed previously, the SQL code might not be portable across DBMS. For instance, creating an automatically increment integer primary key in a table is DBMS specific.\n \u2022 The string is fragile if the database schema changes. Finding whether a schema change impacts any of the\n queries requires looking at all the strings in your application.\n \u2022 performance might be an issue. Whenever you execute a query, the DBMS will analyze it, decide how to execute\n it (for instance, whether it should traverse all the rows of a table, or whether it can do a faster lookup), and then\n \n@@ -178,124 +178,125 @@\n Chapter 1. SQL: Database interface\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n 1.2 Database example\n This section describes an example that will be extended throughout this chapter. We will build an application that\n represents a library. Such a library contains various media (books and DVDs for instance), and customers. A customer\n-can borrow multiple media at the same time, but a media is either at a customer's, or still in the library.\n+can borrow multiple media at the same time, but a media is either at a customer\u2019s, or still in the library.\n The GNATColl distribution includes an example directory which contains all the code and data for this example.\n \n 1.3 Database schema\n As was mentioned earlier (Database Abstraction Layers), GNATColl relies on automatic code generation to provide a\n type safe interface to your database. This code is generated by an external tool called gnatcoll_db2ada. In some cases,\n this tool requires an installation of python (www.python.org) on your machine, since part of the code is written in that\n language.\n This tool is able to output various kind of information, and will be fully described later (The gnatcoll_db2ada tool).\n However, the input is always the same: this is the schema of your database, that is the list of tables and fields that make\n up your database. There exist two ways to provide that information:\n \u2022 From a running database\n-If you pass the DBMS vendor (postgresql, sqlite,...) and the connection parameters to gnatcoll_db2ada, it is\n+If you pass the DBMS vendor (postgresql, sqlite,. . . ) and the connection parameters to gnatcoll_db2ada, it is\n able to query the schema on its own. However, this should not be the preferred method: this is similar to reverse\n engineering assembly code into the original high-level code, and some semantic information will be missing. For\n instance, in SQL we have to create tables just to represent the many-to-many relationships. These extra tables\n are part of the implementation of the schema, but are just noise when it comes to the semantics of the schema.\n For this reason, it is better to use the second solution below:\n \u2022 From a textual description\n Using the -dbmodel switch to gnatcoll_db2ada, you can pass a file that describes the schema. We do not use\n SQL as the syntax in this, because as explained above this is too low-level. This text file also provides additional\n capabilities that do not exist when reverse-engineering an existing database, for instance the ability to use name\n to represent reverse relationships for foreign keys (see below and the ORM).\n The most convenient editor for this file is Emacs, using the org-mode which provides convenient key shortcuts\n for editing the contents of ASCII tables. But any text editor will do, and you do not need to align the columns in\n this file.\n-All lines starting with a hash sign ('#') will be ignored.\n+All lines starting with a hash sign (\u2018#\u2019) will be ignored.\n This file is a collection of ASCII tables, each of which relates to one table or one SQL view in your database.\n The paragraphs start with a line containing:\n table ::=\n '|' ('ABSTRACT')? ('TABLE'|'VIEW') ['(' supertable ')']\n '|' <name> '|' <name_row>\n-\"name\" is the name of the table. The third pipe and third column are optional, and should be used to specify the\n-name for the element represented by a single row. For instance, if the table is called \"books\", the third column\n-could contain \"book\". This is used when generating objects for use with GNATCOLL.SQL.ORM.\n+\u201cname\u201d is the name of the table. The third pipe and third column are optional, and should be used to specify the\n+name for the element represented by a single row. For instance, if the table is called \u201cbooks\u201d, the third column\n+could contain \u201cbook\u201d. This is used when generating objects for use with GNATCOLL.SQL.ORM.\n If the first line starts with the keyword ABSTRACT, then no instance of that table actually exists in the database.\n This is used in the context of table inheritance, so define shared fields only once among multiple tables.\n The keyword TABLE can be followed by the name of a table from which it inherits the fields. Currently, that\n supertable must be abstract, and the fields declared in that table are simply duplicated in the new table.\n \n 1.2. Database example\n \n 3\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n Following the declaration of the table, the file then describe their fields, each on a separate line. Each of these\n-lines must start with a pipe character (\"|\"), and contain a number of pipe-separated fields. The order of the fields\n+lines must start with a pipe character (\u201c|\u201d), and contain a number of pipe-separated fields. The order of the fields\n is always given by the following grammar:\n fields ::=\n '|' <name> '|' <type>\n '|' ('PK'|''|'NULL'|'NOT NULL'|'INDEX'|'UNIQUE'|'NOCASE')\n '|' [default] '|' [doc] '|'\n-The type of the field is the SQL type (\"INTEGER\", \"TEXT\", \"TIMESTAMP\", \"DATE\", \"DOUBLE PRECISION\", \"MONEY\", \"BOOLEAN\", \"TIME\", \"CHARACTER(1)\"). Any maximal length can be specified for\n-strings, not just 1 as in this example. The tool will automatically convert these to Ada when generating Ada\n-code. A special type (\"AUTOINCREMENT\") is an integer that is automatically incremented according to available ids in the table. The exact type used will depend on the specific DBMS.\n-The property 'NOCASE' indicates that comparison should be case insensitive for this field.\n+The type of the field is the SQL type (\u201cINTEGER\u201d, \u201cTEXT\u201d, \u201cTIMESTAMP\u201d, \u201cDATE\u201d, \u201cDOUBLE PRECISION\u201d, \u201cMONEY\u201d, \u201cBOOLEAN\u201d, \u201cTIME\u201d, \u201cCHARACTER(1)\u201d). Any maximal length can be specified for\n+strings, not just 1 as in this example. The tool will automatically convert these to Ada when generating Ada code.\n+A special type (\u201cAUTOINCREMENT\u201d) is an integer that is automatically incremented according to available ids\n+in the table. The exact type used will depend on the specific DBMS.\n+The property \u2018NOCASE\u2019 indicates that comparison should be case insensitive for this field.\n If the field is a foreign key (that is a value that must correspond to a row in another table), you can use the special\n syntax for its type:\n fk_type ::= 'FK' <table_name> [ '(' <reverse_name> ')' ]\n-As you can see, the type of the field is not specified explicitly, but will always be that of the foreign table's primary\n+As you can see, the type of the field is not specified explicitly, but will always be that of the foreign table\u2019s primary\n key. With this syntax, the foreign table must have a single field for its primary key. GNATColl does not force a\n-specific order for the declaration of tables: if is valid to have a foreign key to a table that hasn't been declared yet.\n+specific order for the declaration of tables: if is valid to have a foreign key to a table that hasn\u2019t been declared yet.\n There is however a restriction if you use the model to create a sqlite database (through the -createdb switch of\n-gnatcoll_db2ada): in this case, a reference to a table that hasn't been defined yet may not be not through a field\n+gnatcoll_db2ada): in this case, a reference to a table that hasn\u2019t been defined yet may not be not through a field\n marked as NOT NULL. This is a limitation of the sqlite backend itself. The solution in this case is to reorder the\n declaration of tables, or drop the NOT NULL constraint.\n Another restriction is that a foreign key that is also a primary key must reference a table that has already been\n defined. You need to reorder the declaration of your tables to ensure this is the case.\n-\"reverse_name\" is the optional name that will be generated in the Ada code for the reverse relationship, in the\n-context of GNATCOLL.SQL.ORM. If the \"reverse_name\" is empty (the parenthesis are shown), no reverse relationship is generated. If the parenthesis and the reverse_name are both omitted, a default name is generated\n+\u201creverse_name\u201d is the optional name that will be generated in the Ada code for the reverse relationship, in the\n+context of GNATCOLL.SQL.ORM. If the \u201creverse_name\u201d is empty (the parenthesis are shown), no reverse relationship is generated. If the parenthesis and the reverse_name are both omitted, a default name is generated\n based on the name of the field.\n The third column in the fields definition indicates the constraints of the type. Multiple keywords can be used if\n-they are separated by commas. Thus, \"NOT NULL, INDEX\" indicates a column that must be set by the user,\n+they are separated by commas. Thus, \u201cNOT NULL, INDEX\u201d indicates a column that must be set by the user,\n and for which an index is created to speed up look ups.\n-\u2013 A primary key (\"PK\")\n-\u2013 The value must be defined (\"NOT NULL\")\n-\u2013 The value can be left undefined (\"NULL\")\n-\u2013 A unique constraint and index (\"UNIQUE\")\n-\u2013 An index should be created for that column (\"INDEX\") to speed up the lookups.\n-\u2013 The automatic index created for a Foreign Key should not be created (\"NOINDEX\"). Every time a field\n-references another table, GNATColl will by default create an index for it, so that the ORM can more efficiently do a reverse query (from the target table's row find all the rows in the current table that reference\n+\u2013 A primary key (\u201cPK\u201d)\n+\u2013 The value must be defined (\u201cNOT NULL\u201d)\n+\u2013 The value can be left undefined (\u201cNULL\u201d)\n+\u2013 A unique constraint and index (\u201cUNIQUE\u201d)\n+\u2013 An index should be created for that column (\u201cINDEX\u201d) to speed up the lookups.\n+\u2013 The automatic index created for a Foreign Key should not be created (\u201cNOINDEX\u201d). Every time a field\n+references another table, GNATColl will by default create an index for it, so that the ORM can more efficiently do a reverse query (from the target table\u2019s row find all the rows in the current table that reference\n that target row). This will in general provide more efficiency, but in some cases you never intend to do the\n reverse query and thus can spare the extra index.\n The fourth column gives the default value for the field, and is given in SQL syntax. Strings must be quoted with\n single quotes.\n \n 4\n \n Chapter 1. SQL: Database interface\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n The fifth column contains documentation for the field (if any). This documentation will be included in the\n-generated code, so that IDEs can provide useful tooltips when navigating your application's code.\n+generated code, so that IDEs can provide useful tooltips when navigating your application\u2019s code.\n After all the fields have been defined, you can specify extract constraints on the table. In particular, if you have\n a foreign key to a table that uses a tuple as its primary key, you can define that foreign key on a new line, as:\n FK ::= '|' \"FK:\" '|' <table> '|' <field_names>*\n '|' <field_names>* '|'\n For instance:\n | TABLE | tableA |\n | FK: | tableB | fieldA1, fieldA2 | fieldB1, fieldB2 |\n It is also possible to create multi-column indexes, as in the following example. In this case, the third column\n contains the name of the index to create. If left blank, a default name will be computed by GNATColl:\n | TABLE | tableA |\n | INDEX: | field1,field2,field3 | name |\n The same way the unique multi-column constraint and index can be created. The name is optional.\n TABLE | tableA |\n UNIQUE: | field1,field2,field3 | name |\n-Going back to the example we described earlier (Database example), let's describe the tables that are involved.\n+Going back to the example we described earlier (Database example), let\u2019s describe the tables that are involved.\n The first table contains the customers. Here is its definition:\n | TABLE | customers\n | customer\n || The customer for the library |\n | id\n | AUTOINCREMENT | PK\n || Auto-generated id\n@@ -306,27 +307,27 @@\n |\n | last | TEXT\n | NOT NULL, INDEX || Customer's last name\n |\n We highly recommend to set a primary key on all tables. This is a field whose value is unique in the table,\n and thus that can act as an identifier for a specific row in the table (in this case for a specific customer). We\n recommend using integers for these ids for efficiency reasons. It is possible that the primary key will be made of\n-several fields, in which case they should all have the \"PK\" constraint in the third column.\n+several fields, in which case they should all have the \u201cPK\u201d constraint in the third column.\n A table with no primary key is still usable. The difference is in the code generated for the ORM (The ObjectRelational Mapping layer (ORM)), since the Delete operation for this table will raise a Program_Error instead\n-of doing the actual deletion (that's because there is no guaranteed unique identifier for the element, so the ORM\n-does not know which one to delete -- we do not depend on having unique internal ids on the table, like some\n+of doing the actual deletion (that\u2019s because 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 unique internal ids on the table, like some\n DBMS have). Likewise, the elements extracted from such a primary key-less table will not be cached locally in\n the session, and cannot be updated (only new elements can be created in the table).\n As we mentioned, the library contains two types of media, books and DVDs. Each of those has a title, an author.\n However, a book also has a number of pages and a DVD has a region where it can be viewed. There are various\n ways to represent this in a database. For illustration purposes, we will use table inheritance here: we will declare\n one abstract table (media) which contains the common fields, and two tables to represent the types of media.\n As we mentioned, a media can be borrowed by at most one customer, but a customer can have multiple media\n at any point in time. This is called a one-to-many relationship. In SQL, this is in general described through the\n-use of a foreign key that goes from the table on the \"many\" side. In this example, we therefore have a foreign key\n+use of a foreign key that goes from the table on the \u201cmany\u201d side. In this example, we therefore have a foreign key\n from media to customers. We also provide a name for the reverse relationship, which will become clearer when\n we describe the ORM interface.\n Here are the declarations:\n \n 1.3. Database schema\n \n 5\n@@ -371,27 +372,27 @@\n | region\n | INTEGER |\n | 1 |\n |\n For this example, all this description is put in a file called dbschema.txt.\n \n 1.4 The gnatcoll_db2ada tool\n-As stated in the introduction, one of the goals of this library is to make sure the application's code follows changes in\n+As stated in the introduction, one of the goals of this library is to make sure the application\u2019s code follows changes in\n the schema of your database.\n To reach this goal, an external tool, gnatcoll_db2ada is provided with GNATColl, and should be spawned as the first\n step of the build process, or at least whenever the database schema changes. It generates an Ada package (Database by\n default) which reflects the current schema of the database.\n This tool supports a number of command line parameters (the complete list of which is available through the -h switch).\n The most important of those switches are:\n -dbhost host, -dbname name, -dbuser user, -dbpasswd passwd, -dbtype type\n These parameters specify the connection parameters for the database. To find out the schema, gnatcoll_db2ada\n can connect to an existing database (Database schema). The user does not need to have write permission on the\n database, since all queries are read-only.\n -dbmodel file\n-This parameter can replace the above -dbname,... It specifies the name of a text file that contains the description\n+This parameter can replace the above -dbname,. . . It specifies the name of a text file that contains the description\n of the database, therefore avoiding the need for already having a database up-and-running to generate the Ada\n interface.\n The format of this text file was described in the previous section.\n This switch is not compatible with -enum and -vars that really need an access to the database.\n -api PKG\n This is the default behavior if you do not specify -text or -createdb. This will generate several files (PKG.ads,\n PKG.adb and PKG_names.ads, where PKG is the argument given on the command line). These package represent your database schema, that is the list of all tables and their fields, as typed values. This is the building block\n@@ -412,18 +413,18 @@\n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n was specified) from your application, without requiring access to the external files that define the schema and the\n initial data.\n -enum table,id,name,prefix,base\n This parameter can be repeated several times if needed. It identifies one of the special tables of the database that\n acts as an enumeration type. It is indeed often the case that one or more tables in the database have a role similar\n-to Ada's enumeration types, i.e. contains a list of values for information like the list of possible priorities, a list\n-of countries,... Such lists are only manipulated by the maintainer of the database, not interactively, and some\n-of their values have impact on the application's code (for instance, if a ticket has an urgent priority, we need to\n-send a reminder every day -- but the application needs to know what an urgent priority is). In such a case, it is\n+to Ada\u2019s enumeration types, i.e. contains a list of values for information like the list of possible priorities, a list\n+of countries,. . . Such lists are only manipulated by the maintainer of the database, not interactively, and some\n+of their values have impact on the application\u2019s code (for instance, if a ticket has an urgent priority, we need to\n+send a reminder every day \u2013 but the application needs to know what an urgent priority is). In such a case, it is\n convenient to generate these values as constants in the generated package. The output will be similar to:\n subtype Priority_Id is Integer;\n Priority_High\n : constant Priority_Id := 3;\n Priority_Medium : constant Priority_Id := 2;\n Priority_Low\n : constant Priority_Id := 1;\n@@ -447,15 +448,15 @@\n | 4\n | internal\n To generate the above Ada code, you need to pass the following parameter to gnatcoll_db2ada:\n -enum ticket_priorities,Priority,Name,Priority,Integer\n First word in the parameter is the table name where the data to generate constants is stored. Second word is the\n field name in the table where the Ada constant value is stored. The third word is the field where the last part\n the Ada constant name is stored. The forth word is the prefix to add in front of the third word field value to\n-generate the Ada constant's name. The last optional parameter should be either Integer (default) or String, which\n+generate the Ada constant\u2019s name. The last optional parameter should be either Integer (default) or String, which\n influences the way how the Ada constant value is going to be generated (surrounded or not by quotes).\n -enum-image\n If specified in addition to the -enum switch, then a function is generated for each Integer-valued enum that\n converts numeric values to the corresponding name as a string.\n This function is generated as an Ada 2012 expression-function such as:\n function Image_Priority_Id (X : Priority_Id) return String is\n (case X is\n@@ -488,15 +489,15 @@\n 1\n | user1\n We could extract the id that helps detect unassigned tickets with the following command line:\n -var no_assign_id,staff,staff_id,\"login='unassigned'\",\"help\"\n which generates:\n No_Assigne_Id : constant := 0;\n -- help\n-The application should use this constant rather than some hard-coded string \"unassigned\" or a named constant\n+The application should use this constant rather than some hard-coded string \u201cunassigned\u201d or a named constant\n with the same value. The reason is that presumably the login will be made visible somewhere to the user, and\n we could decide to change it (or translate it to another language). In such a case, the application would break.\n On the other hand, using the constant 0 which we just extracted will remain valid, whatever the actual text we\n display for the user.\n -orm PKG\n This will generate two files (PKG.ads and PKG.adb) that support GNATCOLL.SQL.ORM to write queries without writing actual SQL. This is often used in conjunction with -api, as in:\n gnatcoll_db2ada -api Database -orm ORM -dbmodel dbschema.txt\n@@ -558,23 +559,23 @@\n \n 1.4.2 database introspection in Ada\n As described above, the -createdb switch makes it possible to create a database (or at least its schema). This operation\n can also be performed directly from your Ada code by using the services provided in the GNATCOLL.SQL.Inspect\n package. In particular, there are services for reading the schema of a database either from a file or from a live database,\n just as gnatcoll_db2ada does.\n This results in a structure in memory that you can use to find out which are the tables, what are their fields, their primary\n-keys,...\n+keys,. . .\n It is also possible to dump this schema to a text file (with the same format as expected by -dbmodel), or more interestingly\n to output the SQL statements that are needed to create the tables in a database. In the case of Sqlite, creating a table\n-will also create the database file if it doesn't exist yet, so no special rights are needed.\n+will also create the database file if it doesn\u2019t exist yet, so no special rights are needed.\n This input/output mechanism is implemented through an abstract Schema_IO tagged type, with various concrete implementations (either File_Schema_IO to read or write from/to a file, or DB_Schema_IO to read or write from/to a\n database).\n See the specs for more detail on these subprograms.\n \n-1.4.3 Back to the library example...\n+1.4.3 Back to the library example. . .\n In the previous section, we have described our database schema in a text file. We will now perform two operations:\n \u2022 Create an empty database\n This should of course only be done once, not every time you run your application:\n 1.4. The gnatcoll_db2ada tool\n \n 9\n \n@@ -615,15 +616,15 @@\n of the box (PostgreSQL and Sqlite), although new ones can be added by overriding the appropriate SQL type\n (Database_Connection). When you compile GNATColl, the build scripts will try and detect what systems are installed on your machine, and only build support for those. It is possible, if no database was installed on your machine\n at that time, that the database interface API is available (and your application compiles), but no connection can be done\n to database at run time.\n To connect to a DBMS, you need to specify the various connection parameters. This is done via a GNATCOLL.SQL.Exec.Database_Description object. The creation of this object depends on the specific DBMS you are\n connecting to (and this is the only part of your code that needs to know about the specific system). The packages\n GNATCOLL.SQL.Postgres and GNATCOLL.SQL.Sqlite contain a Setup function, whose parameters depend on the\n-DBMS. They provide full documentation for their parameters. Let's take a simple example from sqlite:\n+DBMS. They provide full documentation for their parameters. Let\u2019s take a simple example from sqlite:\n with GNATCOLL.SQL.Sqlite;\n -- or Postgres\n declare\n DB_Descr : GNATCOLL.SQL.Exec.Database_Description;\n (continues on next page)\n \n 10\n@@ -683,15 +684,15 @@\n \n In all three cases, the resulting database connection needs to be freed when you no longer needed (which might be\n when your program terminates if you are using pools) to avoid memory leaks. Nothing critical will appear if you do\n not close, though, because the transactions to the DBMS server are saved every time you call Commit in any case. So\n the code would end with:\n Free (DB); -- for all connections you have opened\n Free (DB_Descr);\n-At this point, there still hasn't been any connection to the DBMS. This will be done the first time a query is executed.\n+At this point, there still hasn\u2019t been any connection to the DBMS. This will be done the first time a query is executed.\n If for some reason the connection to the DBMS server is lost, GNATColl will automatically attempt to reconnect a\n number of times before it gives up. This might break if there was an ongoing SQL transaction, but simplifies your code\n since you do not have to handle reconnection when there was a network failure, for instance.\n As we saw before, the database interface can be used in multi-tasking applications. In such a case, it is recommended\n that each thread has its own connection to the database, since that is more efficient and you do not have to handle\n locking. However, this assumes that the database server itself is thread safe, which most often is the case, but not for\n sqlite for instance. In such a case, you can only connect one per application to the database, and you will have to manage\n@@ -704,22 +705,22 @@\n initial data.\n There are various ways to do it:\n \u2022 Manually or with an external tool\n One can connect to the database with an external tool (a web interface when the DBMS provides one for instance),\n or via a command line tool (psql for PostgreSQL or sqlite3 for Sqlite), and start inserting data manually. This\n shows one of the nice aspects of using a standard DBMS for your application: you can alter the database (for\n instance to do minor fixes in the data) with a lot of external tools that were developed specifically for that purpose\n-and that provide a nice interface. However, this is also tedious and error prone, and can't be repeat easily every\n+and that provide a nice interface. However, this is also tedious and error prone, and can\u2019t be repeat easily every\n time we recreate the database (for instance before running automatic tests).\n \u2022 Using GNATCOLL.SQL.EXEC\n As we will describe later, GNATColl contains all the required machinery for altering the contents of the database\n and creating new objects. Using GNATCOLL.SQL.ORM this can also be done at a high-level and completely\n hide SQL.\n \u2022 Loading a data file\n-A lot of frameworks call such a file that contains initial data a \"fixture\". We will use this technique as an example.\n+A lot of frameworks call such a file that contains initial data a \u201cfixture\u201d. We will use this technique as an example.\n At the Ada level, this is a simple call to GNATCOLL.SQL.Inspect.Load_Data. The package contains a lot more\n than just this subprogram (The gnatcoll_db2ada tool):\n declare\n File : GNATCOLL.VFS.Virtual_File := Create (\"fixture.txt\");\n DB : Database_Connection; -- created earlier\n begin\n GNATCOLL.SQL.Inspect.Load_Data (DB, File);\n@@ -732,15 +733,15 @@\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n The format of this file is described just below.\n As we mentioned, GNATColl can load data from a file. The format of this file is similar to the one that describes the\n database schema. It is a set of ASCII tables, each of which describes the data that should go in a table (it is valid to\n duplicate tables). Each block starts with two lines: The first one has two mandatory columns, the first of which contains\n-the text \"TABLE\", and the second contains the name of the table you want to fill. The second line should contain as\n+the text \u201cTABLE\u201d, and the second contains the name of the table you want to fill. The second line should contain as\n many columns as there are fields you want to set. Not all the fields of the table need to have a corresponding column if\n you want to set their contents to NULL (provided, of course, that your schema allows it). For instance, we could add\n data for our library example as such:\n | TABLE | customers |\n |\n |\n id | first\n@@ -790,15 +791,15 @@\n 1 | &Smith\n |\n | The Dictator | Chaplin\n |\n 3 | &Dupont\n |\n Here, the title of the column indicates that any value in this column might be a reference to the customers.last value.\n-Values which start with an ampersand (\"&\") will therefore be looked up in customers.last, and the id of the corresponding customer will be inserted in the dvds table. It would still be valid to use directly customer ids instead of references,\n+Values which start with an ampersand (\u201d&\u201d) will therefore be looked up in customers.last, and the id of the corresponding customer will be inserted in the dvds table. It would still be valid to use directly customer ids instead of references,\n this is just an extra flexibility that the references give you to make your fixtures more readable.\n However, if we are using such references we need to provide the database schema to Load_Data so that it can write the\n proper queries. This is done by using other services of the GNATCOLL.SQL.Inspect package.\n The code for our example would be:\n Load_Data\n (DB, Create (\"fixture.txt\"),\n New_Schema_IO (Create (\"dbschema.txt\")).Read_Schema);\n@@ -829,21 +830,21 @@\n & Ticket_Priorities.Category,\n From\n => Ticket_Priorities,\n Where => Ticket_Priorities.Name /= \"low\",\n Group_By => Ticket_Priorities.Category);\n end;\n The above example will return, for each type of priority (internal or customer) the highest possible value. The interest\n-of this query is left to the user...\n+of this query is left to the user. . .\n This is very similar to an actual SQL query. Field and table names come from the package that was automatically\n generated by the gnatcoll_db2ada tool, and therefore we know that our query is only referencing existing fields. The\n syntactic correctness is ensured by standard Ada rules. The SQL_Select accepts several parameters corresponding to\n the usual SQL attributes like GROUP BY, HAVING, ORDER BY and LIMIT.\n The From parameter could be a list of tables if we need to join them in some ways. Such a list is created with the\n-overridden \"&\" operator, just as for fields which you can see in the above example. GNATColl also provides a Left_Join\n+overridden \u201c&\u201d operator, just as for fields which you can see in the above example. GNATColl also provides a Left_Join\n function to join two tables when the second might have no matching field (see the SQL documentation).\n Similar functions exist for SQL_Insert, SQL_Update and SQL_Delete. Each of those is extensively documented in the\n gnatcoll-sql.ads file.\n It is worth noting that we do not have to write the query all at once. In fact, we could build it depending on some other\n criteria. For instance, imagine we have a procedure that does the query above, and omits the priority specified as a\n parameter, or shows all priorities if the empty string is passed. Such a procedure could be written as:\n procedure List_Priorities (Omit : String := \"\") is\n@@ -874,16 +875,16 @@\n Auto_Complete (Q);\n This query is exactly the same as before. However, we did not have to specify the list of tables (which GNATColl\n can compute on its own by looking at all the fields referenced in the query), nor the list of fields in the GROUP BY\n clause, which once again can be computed automatically by looking at those fields that are not used in a SQL aggregate\n function. This auto-completion helps the maintenance of those queries.\n There is another case where GNATColl makes it somewhat easier to write the queries, and that is to handle joins\n between tables. If your schema was build with foreign keys, GNATColl can take advantage of those.\n-Going back to our library example, let's assume we want to find out all the books that were borrowed by the user\n-\"Smith\". We need to involve two tables (Books and Customers), and provide a join between them so that the DBMS\n+Going back to our library example, let\u2019s assume we want to find out all the books that were borrowed by the user\n+\u201cSmith\u201d. We need to involve two tables (Books and Customers), and provide a join between them so that the DBMS\n knows how to associate the rows from one with the rows from the other. Here is a first example for such a query:\n Q := SQL_Select\n (Fields => Books.Title & Books.Pages,\n From\n => Books & Customers,\n Where => Books.Borrowed_By = Customers.Id\n and Customers.Last = \"Smith\");\n@@ -891,15 +892,15 @@\n the simpler:\n Q := SQL_Select\n (Fields => Books.Title & Books.Pages,\n Where => Books.Borrowed_By = Customers.Id\n and Customers.Last = \"Smith\");\n There is one more things we can do to simplify the query and make it more solid if the schema of the database changes.\n For instance, when a table has a primary key made up of several fields, we need to make sure we always have an\n-\"=\" statement in the WHERE clause for all these fields between the two tables. In our example above, we could at\n+\u201c=\u201d statement in the WHERE clause for all these fields between the two tables. In our example above, we could at\n some point modify the schema so that the primary key for customers is multiple (this is unlikely in this example of\n course). To avoid this potential problems and make the query somewhat easier to read, we can take advantage of the\n FK subprograms generated by gnatcoll_db2ada. Using the Ada05 dotted notation for the call, we can thus write:\n Q := SQL_Select\n (Fields => Books.Title & Books.Pages,\n Where => Books.FK (Customers)\n and Customers.Last = \"Smith\");\n@@ -923,15 +924,15 @@\n This reuses the connection we have established previously (DB) (although now we are indeed connecting to the DBMS\n for the first time) and sends it the query. The result of that query is then stored in R, to be used later.\n Some SQL commands execute code on the DBMS, but do not return a result. In this case, you can use Execute instead\n of Fetch. This is the case when you execute an INSERT or UPDATE statement for instance. Using Execute avoids the\n need to declare the local variable R.\n If for some reason the connection to the database is no longer valid (a transient network problem for instance), GNATColl will attempt to reconnect and re-execute your query transparently, so that your application does not need to handle\n this case.\n-We'll describe later (Getting results) how to analyze the result of the query.\n+We\u2019ll describe later (Getting results) how to analyze the result of the query.\n Some versions of Fetch have an extra parameter Use_Cache, set to False by default. If this parameter is true, and\n the exact same query has already been executed before, its result will be reused without even contacting the database\n server. The cache is automatically invalidated every hour in any case. This cache is mostly useful for tables that act\n like enumeration types, as we have seen before when discussing the -enum parameter to gnatcoll_db2ada. In this\n case, the contents of the table changes very rarely, and the cache can provide important speedups, whether the server is\n local or distant. However, we recommend that you do actual measurements to know whether this is indeed beneficial\n for you. You can always invalidate the current cache with a call to Invalidate_Cache to force the query to be done on\n@@ -989,15 +990,15 @@\n Q : constant SQL_Query :=\n SQL_Select\n (Fields => Data.Id & Data.Name\n From\n => Data,\n Where => Data.Id = Integer_Param (1));\n GNATColl provides a number of functions (one per type of field) to indicate that the value is currently unbound.\n-Integer_Param, Text_Param, Boolean_Param,... All take a single argument, which is the index of the corresponding\n+Integer_Param, Text_Param, Boolean_Param,. . . All take a single argument, which is the index of the corresponding\n parameter. A query might need several parameters, and each should have a different index. On the other hand, the same\n parameter could be used in several places in the query.\n Although the query above could be executed as is by providing the values for the parameters, it is more efficient, as\n we mentioned at the beginning, to compile it on the server. In theory, this preparation is done within the context of a\n database connection (thus cannot be done for a global variable, where we do not have connections yet, and where the\n query might be executed by any connection later on).\n GNATColl will let you indicate that the query should be prepared. This basically sets up some internal data, but does\n@@ -1015,32 +1016,32 @@\n P : constant Prepared_Statement :=\n Prepare (Q, On_Server => True);\n Two comments about this code:\n \u2022 You do not have to use global variables. You can prepare the statement locally in a subprogram. A Prepared_Statement is a reference counted type, that will automatically free the memory on the server when it\n goes out of scope.\n \u2022 Here, we prepared the statement on the server. If we had specified On_Server => False, we would still have\n sped things up, since Q would be converted to a string that can be sent to the DBMS, and from then on reused\n-that string (note that this conversion is specific to each DBMS, since they don't always represent things the same\n+that string (note that this conversion is specific to each DBMS, since they don\u2019t always represent things the same\n way, in particular parameters, as we have seen above). Thus every time you use P you save the time of converting\n from the GNATColl tree representation of the query to a string for the DBMS.\n Now that we have a prepared statement, we can simply execute it. If the statement does not require parameters, the\n usual Fetch and Execute subprograms have versions that work exactly the same with prepared statements. They also\n-accept a Params parameter that contains the parameter to pass to the server. A number of \"+\" operators are provided\n+accept a Params parameter that contains the parameter to pass to the server. A number of \u201c+\u201d operators are provided\n to create those parameters:\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-Note that for string parameters, the \"+\" operator takes an access to a string. This is for efficiency, to avoid allocating\n+Note that for string parameters, the \u201c+\u201d operator takes an access to a string. This is for efficiency, to avoid allocating\n memory and copying the string, and is safe because the parameters are only needed while Fetch executes (even for a\n Forward_Cursor.\n Back to our library example. We showed earlier how to write a query that retrieves the books borrowed by customer\n-\"Smith\". We will now make this query more general: given a customer name, return all the books he has borrowed.\n+\u201cSmith\u201d. We will now make this query more general: given a customer name, return all the books he has borrowed.\n Since we expect to use this often, we will prepare it on the server (in real life, this query is of little interest since the\n customer name is not unique, we would instead use a query that takes the id of the customer). In general we would\n create a global variable with:\n Borrowed : constant Prepared_Statement := Prepare\n (SQL_Select\n (Fields => Books.Title & Books.Pages,\n Where => Books.FK (Customers)\n@@ -1094,15 +1095,15 @@\n it proves efficient, since only one row needs to be kept in memory at any point in time.\n For each row, we then call one of the Value or *Value functions which return the value in a specific row and a specific\n column.\n We mentioned earlier there was no way to go back to a row you fetched previously except by executing the query again.\n This is in fact only true if you use a Forward_Cursor to fetch the results.\n But GNATColl provides another notion, a Direct_Cursor. In this case, it fetches all the rows in memory when the\n query executes (thus it needs to allocate more memory to save every thing, which can be costly if the query is big).\n-This behavior is supported natively by PostgreSQL, but doesn't exist with sqlite, so GNATColl will simulate it as\n+This behavior is supported natively by PostgreSQL, but doesn\u2019t exist with sqlite, so GNATColl will simulate it as\n efficiently as possible. But it will almost always be faster to use a Forward_Cursor.\n In exchange for this extra memory overhead, you can now traverse the list of results in both directions, as well as access\n a specific row directly. It is also possible to know the number of rows that matched (something hard to do with a\n Forward_Cursor since you would need to traverse the list once to count, and then execute the query again if you need\n the rows themselves).\n \n 1.10. Getting results\n@@ -1180,31 +1181,31 @@\n See also GNATCOLL.SQL_Fields for an example on how to have a full integration with other parts of GNATCOLL.SQL.\n \n 1.12 Query logs\n The GNATCOLL.Traces package provides facilities to add logging. The database interface uses this module to log the\n queries that are sent to the server.\n If you activate traces in your application, the user can then activate one of the following trace handles to get more\n information on the exchange that exists between the database and the application. As we saw before, the output of these\n-traces can be sent to the standard output, a file, the system logs,...\n+traces can be sent to the standard output, a file, the system logs,. . .\n The following handles are provided:\n \u2022 SQL.ERROR This stream is activated by default. Any error returned by the database (connection issues, failed\n-transactions,...) will be logged on this stream\n+transactions,. . . ) will be logged on this stream\n \u2022 SQL This stream logs all queries that are not SELECT queries, i.e. mostly all queries that actually modify the\n database\n \u2022 SQL.SELECT This stream logs all select queries. It is separated from SQL because very often you will be mostly\n interested in the queries that impact the database, and logging all selects can generate a lot of output.\n In our library example, we would add the following code to see all SQL statements executed on the server:\n with GNATCOLL.Traces; use GNATCOLL.Traces;\n procedure Main is\n begin\n GNATCOLL.Traces.Parse_Config_File (\".gnatdebug\");\n ... -- code as before\n GNATCOLL.Traces.Finalize; -- reclaim memory\n and then create a .gnatdebug in the directory from which we launch our executable. This file would contain a single\n-line containing \"+\" to activate all log streams, or the following to activate only the subset of fields related to SQL:\n+line containing \u201c+\u201d to activate all log streams, or the following to activate only the subset of fields related to SQL:\n SQL=yes\n SQL.SELECT=yes\n SQL.LITE=yes\n \n 1.12. Query logs\n \n 21\n@@ -1225,15 +1226,15 @@\n end record;\n type My_Cursor is new Forward_Cursor with null record;\n function Element (Self : My_Cursor) return My_Row;\n function Do_Query (DB, ...) return My_Cursor;\n The idea is that you create a function that does the query for you (based on some parameters that are not shown here),\n and then returns a cursor over the resulting set of rows. For each row, you can use the Element function to get an Ada\n record for easier manipulation.\n-Let's first see how these types would be used in practice:\n+Let\u2019s first see how these types would be used in practice:\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 end loop;\n@@ -1301,15 +1302,15 @@\n override those two subprograms to return correct values.\n \n 1.14 The Object-Relational Mapping layer (ORM)\n GNATColl provides a high-level interface to manipulate persistent objects stored in a database, using a common\n paradigm called an object-relational mapping. Such mappings exist for most programming languages. In the design of\n GNATColl, we were especially inspired by the python interface in django and sqlalchemy, although the last two rely\n on dynamic run time introspection and GNATColl relies on code generation instead.\n-This API is still compatible with GNATCOLL.SQL. In fact, we'll show below cases where the two are mixed. It can also\n+This API is still compatible with GNATCOLL.SQL. In fact, we\u2019ll show below cases where the two are mixed. It can also\n be mixed with GNATCOLL.SQL.Exec, although this might be more risky. Communication with the DBMS is mostly\n transparent in the ORM, and it uses various caches to optimize things and make sure that if you modify an element the\n next query(ies) will also return it. If you use GNATCOLL.SQL.Exec directly you are bypassing this cache so you risk\n getting inconsistent results in some cases.\n In ORM, a table is not manipulated directly. Instead, you manipulate objects that are read or written to a table. When\n we defined our database schema (Database schema), we gave two names on the first line of a table definition. There\n was the name of the table in the database, and the name of the object that each row represent. So for our library example\n@@ -1333,43 +1334,43 @@\n |\n | 100 |\n |\n | borrowed_by\n | FK customers(borrowed_books) | NULL |\n | Who borrowed the media\n |\n-Let's thus start by generating this code. We can replace the command we ran earlier (with the -api switch) with one\n+Let\u2019s thus start by generating this code. We can replace the command we ran earlier (with the -api switch) with one\n that will also generate the ORM API:\n gnatcoll_db2ada -dbmode dbschema.txt -api Database -orm ORM\n The ORM provides a pool of database connections through the package GNATCOLL.SQL.Sessions. A session therefore\n acts as a wrapper around a connection, and provides a lot more advanced features that will be described later. The first\n thing to do in the code is to configure the session pool. The Setup procedure takes a lot of parameters to make sessions\n highly configurable. Some of these parameters will be described and used in this documentation, others are for special\n usage and are only documented in gnatcoll-sql-sessions.ads. Here will we use only specify the mandatory\n parameters and leave the default value for the other parameters:\n GNATCOLL.SQL.Sessions.Setup\n (Descr => GNATCOLL.SQL.Sqlite.Setup (\"library.db\"),\n Max_Sessions => 2);\n The first parameter is the same Database_Description we saw earlier (Connecting to the database), but it will be freed\n automatically by the sessions package, so you should not free it yourself.\n-Once configure, we can now request a session. Through a session, we can perform queries on the database, make\n-objects persistent, write the changes back to the database,.... We configured the session pool to have at most 2 sessions.\n-The first time we call Get_New_Session, a new session will be created in the pool and marked as busy. While you have a\n+Once configure, we can now request a session. Through a session, we can perform queries on the database, make objects\n+persistent, write the changes back to the database,. . . . We configured the session pool to have at most 2 sessions. The\n+first time we call Get_New_Session, a new session will be created in the pool and marked as busy. While you have a\n reference to it in your code (generally as a local variable), the session belongs to this part of the code. When the session\n is no longer in scope, it is automatically released to the pool to be reused for the next call to Get_New_Session. If you\n call Get_New_Session a second time while some part of your code holds a session (for instance in a different task), a\n new session will be created. But if you do that a third time while the other two are busy, the call to Get_New_Session\n is blocking until one of the two sessions is released to the pool.\n This technique ensures optimal use of the resources: we avoid creating a new session every time (with the performance\n cost of connecting to the database), but also avoid creating an unlimited number of sessions which could saturate the\n server. Since the sessions are created lazily the first time they are needed, you can also configure the package with a\n large number of sessions with a limited cost.\n-Let's then take a new session in our code:\n+Let\u2019s then take a new session in our code:\n Session : constant Session_Type := Get_New_Session;\n-and let's immediately write our first simple query. A customer comes at the library, handles his card and we see his id\n+and let\u2019s immediately write our first simple query. A customer comes at the library, handles his card and we see his id\n (1). We need to look up in the database to find out who he is. Fortunately, there is no SQL to write for this:\n C : ORM.Detached_Customer'Class := Get_Customer (Session, Id => 1);\n The call to Get_Customer performs a SQL query transparently, using prepared statements for maximum efficiency.\n This results in a Customer object.\n ORM is the package that was generated automatically by gnatcoll_db2ada. For each table in the database, it generates\n a number of types:\n \u2022 Customer\n@@ -1382,15 +1383,15 @@\n \n This type represents a row of the Customers table. It comes with a number of primitive operations, in particular\n one for each of the fields in the table. Such an object is returned by a cursor, similarly to what was described in\n the previous section (Writing your own cursors). This object is no longer valid as soon as the cursor moves to\n the next row (in the currently implementation, the 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 copy of the value of the fields, only reference\n the memory that is already allocated for the cursor.\n-This object redefines the equality operator (\"=\") to compare the primary key fields to get expected results.\n+This object redefines the equality operator (\u201c=\u201d) to compare the primary key fields to get expected results.\n \u2022 Detached_Customer\n A detached object is very similar to the Customer object, but it will remain valid even if the cursor moves or\n is destroyed. In fact, the object has made a copy of the value for all of its fields. This object is heavier than a\n Customer, but sometimes easier to manager. If you want to store an object in a data structure, you must always\n store a detached object.\n A detached object also embeds a cache for its foreign keys. In the context of our demo for instance, a Book object\n was borrowed by a customer. When returning from a query, the book knows the id of that customer. But if call\n@@ -1401,30 +1402,30 @@\n This type extends a Forward_Cursor (Getting results). In addition to the usual Has_Row and Next operations, it\n also provides an Element operation that returns a Customer for easy manipulation of the results.\n \u2022 Direct_Customer_List\n This type extends a Direct_Cursor. It also adds a Element operation that returns a Customer element.\n \u2022 Customers_Managers\n This type is the base type to perform queries on the DBMS. A manager provides a number of primitive operations\n which end up creating a SQL query operation in the background, without making that explicit.\n-Let's first write a query that returns all books in the database:\n+Let\u2019s first write a query that returns all books in the database:\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 B := BL.Element;\n Put_Line (\"Book: \" & B.Title);\n Put_Line (\"\n Borrowed by: \" & B.Borrowed_By.Last);\n BL.Next;\n end loop;\n end;\n The manager M corresponds to a query that returns all the books in the database. The second line then executes\n-the query on the database, and returns a list of books. We then traverse the list. Note how we access the book's\n+the query on the database, and returns a list of books. We then traverse the list. Note how we access the book\u2019s\n title by calling a function, rather than by the index of a field as we did with GNATCOLL.SQL.Exec with Value(B,\n 0). The code is much less fragile this way.\n The line that calls Borrowed_By will execute an additional SQL query for each book. This might be inefficient\n if there is a large number of books. We will show later how this can be optimized.\n \n 1.14. The Object-Relational Mapping layer (ORM)\n \n@@ -1437,15 +1438,15 @@\n operations. Those operations are all declared in the package GNATCOLL.SQL.ORM.Impl if you want to look at\n the documentation. Here are those operations:\n \u2013 Get and Get_Direct\n As seen in the example above, these are the two functions that execute the query on the database, and returns\n a list of objects (respectively a Customer_List and a Direct_Customer_List).\n \u2013 Distinct\n Returns a copy of the manager that does not return twice a row with the same data (in SQL, this is the\n-\"DISTINCT\" operator)\n+\u201cDISTINCT\u201d operator)\n \u2013 Limit (Count : Natural; From : Natural := 0)\n Returns a copy of the manager that returns a subset of the results, for instance the first Count ones.\n \u2013 Order_By (By : SQL_Field_List)\n Returns a copy of the manager that sorts the results according to a criteria. The criteria is a list of field as\n was defined in GNATCOLL.SQL. We can for instance returns the list of books sorted by title, and only the\n first 5 books, by replacing M with the following:\n M : Books_Managers := All_Books.Limit (5).Order_By (Books.Title);\n@@ -1454,15 +1455,15 @@\n by Alexandre Dumas by using:\n M : Books_Managers := All_Books.Filter (Author => \"Dumas\");\n This version only provides the equality operator for the fields of the table itself. If for instance we wanted\n all books with less than 50 pages, we would use the second version of filter. This version takes a GNATCOLL.SQL.SQL_Criteria similar to what was explained in previous sections, and we would write:\n M : Books_Managers := All_Books.Filter (Condition => Books.Pages < 50);\n More complex conditions are possible, involving other tables. Currently, the ORM does not have a very\n user-friendly interface for those, but you can always do this by falling back partially to SQL. For instance,\n-if we want to retrieve all the books borrowed by user \"Smith\", we need to involve the Customers table, and\n+if we want to retrieve all the books borrowed by user \u201cSmith\u201d, we need to involve the Customers table, and\n thus make a join with the Books table. In the future, we intend to make this join automatic, but for now you\n will need to write:\n M : Books_Managers := All_Books.Filter\n (Books.FK (Customers)\n and Customers.Last = \"Smith\");\n -- SQL query: SELECT books.pages, books.borrowed_by, books.id,\n -books.title, books.author, books.published\n@@ -1486,15 +1487,15 @@\n Depth indicates on how many levels the objects should be retrieved. For instance, assume we change the\n schema such that a Book references a Customer which references an Address. If we pass 1 for Depth, the\n data for the book and the customer will be retrieved. If however you then call B.Borrowed_By.Address\n this will result in a query. So if you pass 2 for Depth the data for book, customers and addresses will be\n retrieved.\n The second parameter related to efficiency. When a foreign key was mentioned as NOT NULL in the schema,\n we know it is always pointing to an existing object in another table. Select_Related will always retrieve\n-such objects. If, however, the foreign key can be null, i.e. there isn't necessarily a corresponding object in\n+such objects. If, however, the foreign key can be null, i.e. there isn\u2019t necessarily a corresponding object in\n the other table, the SQL query needs to use a LEFT JOIN, which is less efficient. By default, GNATColl\n will not retrieve such fields unless Follow_Left_Join was set to True.\n In our example, a book is not necessarily borrowed by a customer, so we need to follow the left joins:\n M : Books_Managers := All_Books.Filter\n (Books.FK (Customers)\n and Customers.Last = \"Smith\")\n .Select_Related (1, Follow_Left_Join => True);\n@@ -1511,17 +1512,17 @@\n BL := C.Borrowed_Books.Get (Session);\n -- SQL: SELECT books.pages, books.borrowed_by, books.id, books.title,\n -books.author, books.published FROM books\n -WHERE books.borrowed_by=1\n Borrowed_Books is a function that was generated because there was a reverse_name. It returns a Books_Managers, so\n we could in fact further filter the list of borrowed books with the same primitive operations we just saw. As you can\n see, the resulting SQL is optimal.\n-Let's optimize further the initial query. We have hard-coded the customer name, but in fact we could be using the same\n+Let\u2019s optimize further the initial query. We have hard-coded the customer name, but in fact we could be using the same\n subprograms we were using for prepared statements (Prepared queries), and even prepare the query on the server for\n-maximum efficiency. Since our application is likely to use this query a lot, let's create a global variable:\n+maximum efficiency. Since our application is likely to use this query a lot, let\u2019s create a global variable:\n M : constant Books_Managers := All_Books.Filter\n (Books.FK (Customers)\n and Customers.Id = Integer_Param (1))\n (continues on next page)\n \n 1.14. The Object-Relational Mapping layer (ORM)\n \n@@ -1539,15 +1540,15 @@\n BL : Book_List := MP.Get (Session, Params => (1 => Smith_Id));\n The last call to Get is very efficient, with timing improvements similar to the ones we discussed on the session about\n prepared statements (Prepared queries).\n \n 1.15 Modifying objects in the ORM\n The ORM is much more than writing queries. Once the objects are persistent, they can also be simplify modified, and\n they will be saved in the database transparently.\n-Let's start with a simple example. In the previous section, we retrieve an object C representing a customer. Let's change\n+Let\u2019s start with a simple example. In the previous section, we retrieve an object C representing a customer. Let\u2019s change\n his name, and make sure the change is in the database:\n C := Get_Customer (Session, 1);\n C.Set_Last (\"Smith\");\n C.Set_First (\"Andrew\");\n Session.Commit;\n A reasonable way to modify the database. However, this opens a can of complex issues that need to be dealt with.\n When we called Set_Last, this modify the objects in memory. At this point, printing the value of C.Last would indeed\n@@ -1586,40 +1587,40 @@\n C := Get_Customer (Session, Id => 1);\n C.Set_Last (\"Lee\");\n CL : Customer_List := All_Customers.Get (Session);\n while CL.Has_Row loop\n Put_Line (CL.Element.Last);\n CL.Next;\n end loop;\n-The above example uses CL.Element, which is a light-weight Customer object. Such objects will only see the inmemory changes if you have set Flush_Before_Query to true when you configured the sessions in the call to GNATCOLL.SQL.Sessions.Setup. Otherwise, it will always return what's really in the database.\n+The above example uses CL.Element, which is a light-weight Customer object. Such objects will only see the inmemory changes if you have set Flush_Before_Query to true when you configured the sessions in the call to GNATCOLL.SQL.Sessions.Setup. Otherwise, it will always return what\u2019s really in the database.\n If the example was using Detached_Customer object (by calling CL.Element.Detach for instance) then GNATColl looks\n up in its internal cache and returns the cached element when possible. This is a subtlety, but this is because an Customer\n only exists as long as its cursor, and therefore cannot be cached in the session. In practice, the Flush_Before_Query\n should almost always be true and there will be not surprising results.\n \n 1.16 Object factories in ORM\n Often, a database table is used to contain objects that are semantically of a different kind. In this section, we will take\n a slightly different example from the library. We no longer store the books and the dvds in separate tables. Instead, we\n have one single media table which contains the title and the author, as well as a new field kind which is either 0 for a\n book or 1 for a dvd.\n-Let's now look at all the media borrowed by a customer:\n+Let\u2019s now look at all the media borrowed by a customer:\n C : constant Customer'Class := Get_Customer (Session, Id => 1);\n ML : Media_List := C.Borrowed_Media.Get (Session);\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-This code works, but requires a case statement. Now, let's imagine the check out procedure is different for a book\n+This code works, but requires a case statement. Now, let\u2019s imagine the check out procedure is different for a book\n and a DVD (for the latter we need to check that the disk is indeed in the box). We would have two subprograms\n-Checkout_Book and Checkout_DVD and call them from the case. This isn't object-oriented programming.\n+Checkout_Book and Checkout_DVD and call them from the case. This isn\u2019t object-oriented programming.\n Instead, we will declare two new types:\n \n 1.16. Object factories in ORM\n \n 29\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n@@ -1630,16 +1631,16 @@\n overriding Checkout (Self : Detached_Book);\n type Detached_DVD is new My_Media with private;\n overriding Checkout (Self : Detached_DVD);\n We could manually declare a new Media_List and override Element so that it returns either of the two types instead of\n a Media. But then we would also need to override Get so that it returns our new list. This is tedious.\n We will instead use an element factory in the session. This is a function that gets a row of a table (in the form of\n a Customer), and returns the appropriate type to use when the element is detached (by default, the detached type\n-corresponding to a Customer is a Detached_Customer, and that's what we want to change).\n-So let's create such a factory:\n+corresponding to a Customer is a Detached_Customer, and that\u2019s what we want to change).\n+So let\u2019s create such a factory:\n function Media_Factory\n (From\n : Base_Element'Class;\n Default : Detached_Element'Class) return Detached_Element'Class\n is\n begin\n if From in Media'Class then\n@@ -1705,17 +1706,17 @@\n \n When manipulating source code, programmers needs to know where the various symbols are defined, where they are\n used, and so on. This is generally available directly from their IDE and editors. But computing this information in the\n first place is tricky, especially for languages that support overloading of subprograms.\n Some compilers like GNAT and gcc can generate this information for Ada code bases. For instance, GNAT will generate\n .ali files, which contain the navigation information, when compiling Ada or SPARK code.\n GNATCOLL.Xref can then be used to parse and aggregate all those files into a single sqlite database, which can be\n-conveniently used to answer queries such as \"give me the declaration for this entity\", \"list all places where this entity is\n-used\", \"show all subprograms that could be called in practice at this dispatching call\", \"what files does this file depend\n-on\", \"show me the call graph for this application\",...\n+conveniently used to answer queries such as \u201cgive me the declaration for this entity\u201d, \u201clist all places where this entity is\n+used\u201d, \u201cshow all subprograms that could be called in practice at this dispatching call\u201d, \u201cwhat files does this file depend\n+on\u201d, \u201cshow me the call graph for this application\u201d,. . .\n To use this package, some initialization needs to be performed first:\n with GNATCOLL.Xref;\n use GNATCOLL.Xref;\n with GNATCOLL.SQL.Sqlite;\n with GNATCOLL.Projects; use GNATCOLL.Projects;\n with GNATCOLL.VFS;\n use GNATCOLL.VFS;\n@@ -1738,15 +1739,15 @@\n Free (Error);\n Parse_All_LI_Files (DB, Tree.Root_Project);\n -- 4\n end Support;\n GNATCOLL needs to be able to find the *li files. For this, it depends on project files (as supported by GNATCOLL.\n Projects). So the first thing to do is to parse the project (step 2).\n We then need to tell GNATCOLL where the cross-reference information need to be aggregated. In this example, it\n-will be stored in a sqlite database on the disk. By using a name \":memory:\" instead, we would create a temporary\n+will be stored in a sqlite database on the disk. By using a name \u201c:memory:\u201d instead, we would create a temporary\n in-memory database. This is in general faster, but uses more memory and needs to be recreated every time the program\n is restarted. We could also decide to store the information in any other database supported by GNATCOLL.SQL.Exec,\n for instance PostgreSQL.\n \n 33\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n@@ -1795,18 +1796,18 @@\n This example will print all the references to the entity that is referenced in file source.ads at line 2 (the column is\n unspecified).\n Step 5 gets a handle on the source file. Here, we depend on the project to find the precise directory in which the source\n file is located. We can of course use an absolute file name instead.\n Step 6 gets handle on the entity referenced on line 2 in this file. Such an entity is the starting point for most queries\n defined in GNATCOLL.Xref.\n Finally, on step 7 and the loop below we iterate over all references, and print their location on the standard output.\n-Let's do a much more complex query: we want to see all references to that entity, but also places where the entity might\n+Let\u2019s do a much more complex query: we want to see all references to that entity, but also places where the entity might\n be called through a renames statement, or called through a dispatching call via an overriding method defined on a child\n tagged type (assuming this is a primitive operation of a tagged type in the first place). We also want to see all locations\n-where a method that overrides \"Method\" is called:\n+where a method that overrides \u201cMethod\u201d is called:\n declare\n Refs : Recursive_References_Cursor;\n begin\n DB.Recursive (Entity, GNATCOLL.Xref.References'Access,\n From_Overriding => True, From_Overridden => True,\n From_Renames => True);\n while Refs.Has_Element loop\n@@ -1822,15 +1823,15 @@\n (continued from previous page)\n \n Refs.Next;\n end loop;\n end;\n As shown above, the programing pattern is always the same.\n GNATCOLL.Xref provides many more subprogram to get information like the list of fields for a record type (or a C\n-structure), the list of primitive operations or methods for a tagged object or a class, the call graph for a subprogram,...\n+structure), the list of primitive operations or methods for a tagged object or a class, the call graph for a subprogram,. . .\n It is also able to extract documentation for an entity from the source code, by looking at the lines of code just before or\n just after the declaration or the body of the entity.\n \n 35\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n@@ -1850,46 +1851,46 @@\n You can of course access the sqlite database directly. Most programming languages have an interface to sqlite. For\n instance python does.\n But GNATCOLL provides a command line tool dedicated to that purpose, named gnatinspect.\n When it is first started on a project, this tool will refresh the xref database by parsing all the ALI files from the project.\n This might take a while (up to several minutes) the first time, unless of course the xref were already up-to-date because\n you had loaded the project in GPS first, or already run gnatinspect.\n gnatinspect then displays an interactive prompt that lets you perform various queries on the database. The full list of\n-queries is available by typing \"help\" at the prompt, but this documentation will demonstrate some of them.\n-Let's first look at a number of command line switches that might be useful:\n-\u2022 --db=ARG: this switch can be used to specify the name of the database.\n-By default, gnatinspect checks in the project whether there exists an attribute IDE'Xref_Database, which should\n-specify a file name (relative to the project's object_dir) for the database.\n-If this attribute does not exist, it defaults to \"gnatinspect.db\" in the project's object directory.\n-If there is no object directory defined in the project, the file is created in the project's directory itself. You can\n-however specify any name, including an absolute path, or a path relative to the project's object directory.\n-An alternative is to specify ':memory:', which creates the database in memory. This is of course a temporary\n+queries is available by typing \u201chelp\u201d at the prompt, but this documentation will demonstrate some of them.\n+Let\u2019s first look at a number of command line switches that might be useful:\n+\u2022 \u2013db=ARG: this switch can be used to specify the name of the database.\n+By default, gnatinspect checks in the project whether there exists an attribute IDE\u2019Xref_Database, which should\n+specify a file name (relative to the project\u2019s object_dir) for the database.\n+If this attribute does not exist, it defaults to \u201cgnatinspect.db\u201d in the project\u2019s object directory.\n+If there is no object directory defined in the project, the file is created in the project\u2019s directory itself. You can\n+however specify any name, including an absolute path, or a path relative to the project\u2019s object directory.\n+An alternative is to specify \u2018:memory:\u2019, which creates the database in memory. This is of course a temporary\n database which will disappear when gnatinspect exits, and cannot be shared with other tools.\n-\u2022 --nightlydb=ARG: this switch can help speed up the initial startup of gnatinspect. The idea is that in a lot of\n+\u2022 \u2013nightlydb=ARG: this switch can help speed up the initial startup of gnatinspect. The idea is that in a lot of\n cases, the software on which a team works is build nightly in a common setup. Running gnatinspect in that setup\n will create or update an xref database. Individual developers can then create their own copy of the database\n-by starting from the contents of the nightly database (which is pointed to by the --nightlydb switch), and then\n-gnatinspect will parse the ALI files in the user's setup that are different from the nightly ones.\n-\u2022 --runtime: by default, gnatinspect will only parse the ALI files from your project (and of course the ones from\n+by starting from the contents of the nightly database (which is pointed to by the \u2013nightlydb switch), and then\n+gnatinspect will parse the ALI files in the user\u2019s setup that are different from the nightly ones.\n+\u2022 \u2013runtime: by default, gnatinspect will only parse the ALI files from your project (and of course the ones from\n imported projects). It will not however parse the ALI files found in predefined directories, like for instance the\n GNAT runtime. This saves time in general. If you click on a call to one of the runtime subprograms in your\n own code, gnatinspect will be able to point you to its declaration. However, you will not have access to the body,\n because the link from declaration to body is found in the ALI files of the runtime.\n-\u2022 --command=ARG: gnatinspect will update the xref database as usual, then execute a command, display its result,\n+\u2022 \u2013command=ARG: gnatinspect will update the xref database as usual, then execute a command, display its result,\n and exit. This can be convenient when calling gnatinspect from another tool, like Emacs or vi.\n \n 37\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n-\u2022 --file=ARG: similar to --command, but reads the commands to execute from a file. The file can contain comments\n-(starting with '--'. See also the --lead switch.\n-\u2022 --lang=LANG:SPEC:BODY:OBJ: specifies a naming scheme for a language. The preferred approach is to use\n-a configuration project file (such as those generated by gprconfig for instance), that would define attributes such\n-as Naming'Spec_Suffix, Naming'Body_Suffix and Compiler'Object_File_Suffix. However, this switch provides an\n+\u2022 \u2013file=ARG: similar to \u2013command, but reads the commands to execute from a file. The file can contain comments\n+(starting with \u2018\u2013\u2019. See also the \u2013lead switch.\n+\u2022 \u2013lang=LANG:SPEC:BODY:OBJ: specifies a naming scheme for a language. The preferred approach is to use a\n+configuration project file (such as those generated by gprconfig for instance), that would define attributes such as\n+Naming\u2019Spec_Suffix, Naming\u2019Body_Suffix and Compiler\u2019Object_File_Suffix. However, this switch provides an\n alternative whereby you can specify the same values directly on the command line. For instance, the equivalent\n of:\n configuration project Autoconf is\n package Naming is\n for Spec_Suffix (\"MyLang\") use \".myl\";\n end Naming;\n package Compiler is\n@@ -1900,29 +1901,29 @@\n --lang=MyLang:.myl::.ali\n A third alternative is to have the same contents as the configuration project file above, directly in your own project\n file. This has the same effect, but needs to be duplicated in each of your project file.\n Given one of the above, and assuming your project file includes:\n for Languages use (\"Ada\", \"MyLang\");\n then any file with the .myl extension will be correctly detected by the project manager, and any .ali file with\n the same base name will be parsed by gnatinspect to find cross-reference information. Remember that the switch\n---config=autoconf.cgpr must be passed to gnatinspect if the information is provided via a config project file.\n-\u2022 --lead=ARG should be used in coordination with --file, and specify lines to ignore from the file. All lines starting\n+\u2013config=autoconf.cgpr must be passed to gnatinspect if the information is provided via a config project file.\n+\u2022 \u2013lead=ARG should be used in coordination with \u2013file, and specify lines to ignore from the file. All lines starting\n with the given prefix will be ignored.\n-\u2022 --basenames: controls the display of file names in the output. By default, gnatinspect outputs full path information.\n-\u2022 --exit: if this switch is specified, gnatinspect updates the xref database and exits immediately.\n-\u2022 --project=ARG or -P ARG specifies the name of the project to load. This switch is mandatory.\n+\u2022 \u2013basenames: controls the display of file names in the output. By default, gnatinspect outputs full path information.\n+\u2022 \u2013exit: if this switch is specified, gnatinspect updates the xref database and exits immediately.\n+\u2022 \u2013project=ARG or -P ARG specifies the name of the project to load. This switch is mandatory.\n \u2022 -X VAR=VALUE is used to specify the value of scenario variables used in your project. This is similar to the\n homonym switch in gprbuild.\n-\u2022 --symlinks should be specified if your project uses symbolic links for files. This will ensure that the links are fully\n+\u2022 \u2013symlinks should be specified if your project uses symbolic links for files. This will ensure that the links are fully\n resolved as stored in the database, and thus that when a file is visible through different links, the information is\n appropriately coalesced in the database for that file.\n-\u2022 --subdirs=ARG is similar to the homonym switch in gprbuild\n-\u2022 --tracefile=ARG is used to point to a file compatible with GNATCOLL.Traces that controls the debug information\n-generated by gnatinspect. By default, gnatinspect parses a file called '.gnatdebug' in the current directory.\n-\u2022 --encoding=ARG is the character encoding used for source and ALI files. By default, gnatinspect assumes they\n+\u2022 \u2013subdirs=ARG is similar to the homonym switch in gprbuild\n+\u2022 \u2013tracefile=ARG is used to point to a file compatible with GNATCOLL.Traces that controls the debug information\n+generated by gnatinspect. By default, gnatinspect parses a file called \u2018.gnatdebug\u2019 in the current directory.\n+\u2022 \u2013encoding=ARG is the character encoding used for source and ALI files. By default, gnatinspect assumes they\n are encoded in UTF-8.\n Once it has finished parsing the xref information, gnatinspect displays an interactive prompt, where a number of commands can be used to perform queries. In a lot of cases, these commands take some file information as argument (either\n just the file, or an entity name and the file in which it is defined).\n 38\n \n Chapter 3. Xref: gnatinspect\n \n@@ -1930,15 +1931,15 @@\n \n The file names can be given as either a base name, or relative to the current directory, or even a full name. But file\n names are ambiguous (even when a full path is specified) when aggregate projects are used. It is valid for a given file\n to be part of multiple aggregate projects, and depending on the project we are considering the result of the xref queries\n might vary).\n To remove the ambiguity, it is possible to specify the project to which the file belongs. The project is specified either\n as a project name (which itself could be ambiguous with aggregate projects), or as a full path.\n-In all commands below, whenever the parameter specifies \":file\", you can use instead \":file:project\" if there are ambiguities. It is also possible not to specify the file, in which case the entity will be looked for in all sources of the\n+In all commands below, whenever the parameter specifies \u201c:file\u201d, you can use instead \u201c:file:project\u201d if there are ambiguities. It is also possible not to specify the file, in which case the entity will be looked for in all sources of the\n project.\n Here is the full list of commands supported by gnatinspect:\n \u2022 decl name:file:line:column is probably the most useful command. Given a reference to an entity, it will indicate\n where the entity is declared. The line and column informations are optional:\n >>> decl Func:file.adb:12\n Func:/some/path/file2.adb:20:9\n \u2022 body name:file:line:column is similar to decl, but will return the location of the body of the entity. When the\n@@ -1963,15 +1964,15 @@\n from which it derives. See also child_types.\n \u2022 methods name:file:line:column returns the list of methods (or primitive operations) for the entity.\n \u2022 method_of name:file:line:column returns the class or tagged type for which the entity is a method.\n \u2022 calls name:file:line:column lists all entities called by the entity. This includes all entities defined within the\n scope of the entity (so for a subprogram this will be the list of local variables, but for a package this includes all\n subprograms and nested packages defined within that package).\n \u2022 callers name:file:line:column lists all entities that call the entity. This information is also available from a call\n-to 'refs', but 'callers' return the callers directly, instead of references to the original entity.\n+to \u2018refs\u2019, but \u2018callers\u2019 return the callers directly, instead of references to the original entity.\n 39\n \n \fGNATCOLL Documentation - Database packages, Release 0.0\n \n \u2022 overrides name:file:line:column returns the entity that is overridden by the entity (generally a method from a\n parent class).\n \u2022 overridden name:file:line:column returns the list of entities that override the parameter (generally methods from\n@@ -1989,15 +1990,15 @@\n \u2022 importing filename lists the files that import the file (via with statements in Ada or #include in C for instance)\n \u2022 imports filename lists the files that the file imports (via with statements in Ada or #include in C for instance). See\n also depends_on.\n \u2022 depends filename lists the files that the file depends on (recursively calling imports)\n \u2022 entities file lists all entities referenced or declared in the file.\n Finally, some commands are not related to entities or source files:\n \u2022 refresh refreshes the contents of the xref database, by parsing all ALI files that have been changed.\n-\u2022 shell Execute a shell command (an alternative is to use '!' as the command).\n+\u2022 shell Execute a shell command (an alternative is to use \u2018!\u2019 as the command).\n \u2022 scenario VARIABLE VALUE changes the value of a scenario variable, and reparse the project.\n \u2022 time command arguments executes the command as usual, and report the time it took to execute it.\n \n 40\n \n Chapter 3. Xref: gnatinspect\n \n"}]}]}]}]}]}]}