Hello! Trying to make first steps with ORM, and still cannot make code generator work. Updated everything, but nothing helps. Unhandled null access dereferencing happens.

Updated environment: Linux x86_64, GNAT 2017 GPL, XMLAda from Git, libgpr from Git, GNATCOLL from Git.

Schema.txt:
`| TABLE | Comm_Watch_Items | Comm_Watch_Item || Snapshots of known items |
| Comm_Watch_Item_Id | AUTOINCREMENT | PK || Auto-generated id |
| Id_On_Service | INTEGER | NOT NULL || Integer id as written in URLs and JSON |
| Id_Character_On_Service | CHARACTER(1) | NOT NULL || Character part of id as written in URLs |
| JSON_In_The_List | TEXT | NULL || JSON snapshot as appearing in the list |
| Date_In_The_List | TIMESTAMP | NULL || Time stamp of JSON snapshot as appearing in the list |
| JSON_Alone | TEXT | NULL || JSON snapshot if opened alone (usually more rich) |
| Date_Alone | TIMESTAMP | NULL || Time stamp of JSON snapshot if opened alone |
| UNIQUE: | Id_On_Service, Id_Character_On_Service | Full_Id_On_Service |

| TABLE | Comm_Watch_Bookmarks | Comm_Watch_Bookmark || Bookmark one-to-many relation (username-to-bookmark) |
| Comm_Watch_Bookmark_Id | AUTOINCREMENT | PK || Auto-generated id |
| Username | TEXT | NOT NULL || Username |
| Bookmark_Id_On_Service | INTEGER | NOT NULL || Integer bookmark id as written in URLs and JSON |
| Bookmark_Character_On_Service | CHARACTER(1) | NOT NULL || Character part of bookmark id as written in URLs |
| FK: | Comm_Watch_Items | Bookmark_Id_On_Service, Bookmark_Character_On_Service | Id_On_Service, Id_Character_On_Service |
| UNIQUE: | Username, Bookmark_Id_On_Service, Bookmark_Character_On_Service | Username_Bookmark |`

gnatcoll_db2ada -api Comm_Watch.Database -orm Comm_Watch.ORM -dbmodel Schema.txt

The problem disappears if I remove foreign key, but that destroys the whole point of ORM. I look at this line and cannot see anything wrong with it. All according to the documentation.

Even if the documentation contains information on the “FK:” lines for multiple foreign keys (implying tables with multiple PKs), both gnatcoll-sql-inspect.adb and dborm.py fails in some way in these cases.

In some obscure cases it seems that dborm.py assumes tables with just one PK. A comprehensive review is recommended. Or better, replace dborm.py by the proposed Ada module.

For example, dborm.py still complains on multiple Fks, cannot see the effect. In other cases there is a mismatch between parameters (see the generated code for functions of reverse relations in case of multiple Fks). In other cases, dborm.py changes second, etc. PK to the first PK (because it assumes it is the only one PK). It has been also detected that even it changes the data type of some FK.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

These values are returned by Postgresql as “35,6 €” or as “$35.6”, for example, which causes a constraint error in the generated ORM. The currency symbol should be cleaned when converting to T_Money (are least for the most used currencies).

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Money is numeric(16,2) which is normally insufficient for financial applications (Money is intended for such applications, is it no?). Types T_Numeric_24_8 and T_Numeric_8_4 should be supported. For example, Forex (foreign currency market) is expressed with at least 6 decimals, many investment funds are also expressed with 6 decimals, etc.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Originally, SQL views were intended to be read-only combination of tables, however some DMBSs support updating views under limiting conditions (by automatically defining triggers to update the involved tables).

That is beyond gnatcoll_all2ada, therefore a new option must be defined for gnatcoll_all2ada: -updatable-views, for example, default false. In this case, no routines to update views shall be generated in the ORM code.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Compound foreign keys are not fully processed by File_IO.Read_Schema in gnatcoll-sql-inspect.adb, emitting multiple messages such as

Invalid foreign key: some_table.some_field references an invalid table or field

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Really gnatcoll_all2ada produces a unknown type “interval”, supposedly ISO8601, whose range is larger than Ada Duration. Runtime errors may arise. At least indicate that in the documentation.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Suppose that the database has a sql schema. If you try gnatcoll_all2ada with no “-omit-schema” then
lots of
tmp_orm:5047:14: error: child unit allowed only at library level
tmp_orm:5440:16: error: missing "is"
are issued by gnatchop.

However, if gnatcoll_all2ada is called with such option, all emitted SQL statements in your program will be rejected because the database sql schema is not in the search path of the database search path.

The solution is to insert in your program a SQL statement indicating the search path:
Execute (Connection => DB (Session),
Query => "set schema '';");

However that should be solved in the generated code, not in your program.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Smallint is mapped to Integer, it should be mapped to Short_Integer instead.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Some fields (Integer, Float, Money, Text, Character, perhaps others) are mapped to entities starting with lower case initials (smallint, bigint, double precision, real, numeric, timestamp with time zone, data, interval, boolean).

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

In this case gnatcoll db2ada reports unknown field type time without time zone.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Some columns seemingly at random in the sql database generated by gnatinspect are case sensitive when by default they would not be. In particular name, language, path, fromEntity, toEntity, fromFile, toFile, and column are case sensitive in the database.

This makes analysing the database manually more difficult and should be an easy fix.

I don't know where xref/generated/gnatcoll-xref-database_names.ads is generated from, but it is clearly visible there that some names are surrounded in extra quotes NC_Path : aliased constant String := """path"""; while most are not NC_Stamp : aliased constant String := "stamp";.

They are mapped to Ada Calendar Time, obtained in GNAT from the Operating System, which already included the time zone. The generate code does not deal with time zones. Also note that SQL ranges are larger than GNAT Time range (reported in a previous issue).

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Trying to run gnatcoll_db2ada without python installed, even though python3 is available, will fail with the following message:

A database error occurred, please try again...
raised GNAT.EXPECT.INVALID_PROCESS : g-expect.adb:1133

This is an extremely unhelpful message. At the very least it should check if python3 command is available, as some systems are moving towards it but don't create a symlink for python for backwards compatibility.

System: Debian Sid, gnat-7, gprbuild-2017-5.
compile_shared.txt

In this case gnatcoll db2ada reports again unknown field type time without time zone.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

For example:
gnatcoll_all2ada should have some parameters to generate:
• if there is a table or view description that starts by (), the 3rd column for tables should be automatically generated as
• if the name of the table or view ends in “s”, the 3rd column should be automatically generated using the name but removing the “s”. However, in some cases the result may not be corrected and should be modified by hand. Think in “currencies”.
• To control producing comments or not.
• To align columns. In addition, column alignment should be global to all tables.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Even if the documentation contains information on the “FK:” lines for multiple foreign keys (implying tables with multiple PKs), both gnatcoll-sql-inspect.adb and dborm.py fails in some way in these cases.

dborm.py generates procedures for the reverse relation. In case of multiple Fks, there is a name conflict as the reverse relation name is the same for all Fks. The solution should be to postfix these routines with the individual FK name.

This solution has been implemented in the proposed replacement of dborm.py in the new Ada package.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

It should be mapped to Ada Long_Float (IEEE 754 Binary64).

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

I have been trying to compile the gnat collections/database and all has worked well so far except that I am having trouble linking the gnatinspect and gnatcoll_db2ada modules. I have used my own prefix but the other options for 'make setup' are the defaults. I have installed gnat 11.3 from Debian/testing.

The error message for gnatinspect is:

gprbuild -p -m --target=x86_64-linux-gnu  -j2 -XLIBRARY_TYPE=static -XXMLADA_BUILD=static -XGPR_BUILD=static -XGNATCOLL_VERSION=0.0 -XBUILD=PROD  gnatinspect.gpr
Setup
   [mkdir]        object directory for project Gnatinspect
Compile
   [Ada]          gnatinspect.adb
Bind
   [gprbind]      gnatinspect.bexch
   [Ada]          gnatinspect.ali
Link
   [link]         gnatinspect.adb
/usr/bin/ld: /opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static/libgnatcoll_sql.a(gnatcoll-sql-exec.o): warning: relocation against `gnatcoll__sql__exec__database_engines__iteratorFD' in read-only section `.text'
/usr/bin/ld: gnatinspect.o: relocation R_X86_64_PC32 against symbol `system__soft_links__abort_defer' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
gprbuild: link of gnatinspect.adb failed
gprbuild: failed command was: /usr/bin/gcc-11 gnatinspect.o b__gnatinspect.o /opt/ides/gnat/gnat-collections/lib/gnatcoll_xref.static/libgnatcoll_xref.a /opt/ides/gnat/gnat-collections/lib/gnatcoll_iconv.static/libgnatcoll_iconv.a /opt/ides/gnat/gnat-collections/lib/gnatcoll_sqlite.static/libgnatcoll_sqlite.a /opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static/libgnatcoll_sql.a /opt/ides/gnat/gnat-collections/lib/gnatcoll.static/libgnatcoll.a /opt/ides/gnat/gprbuild/lib/gpr/static/gpr/libgpr.a -L/usr/lib/x86_64-linux-gnu/ -lxmlada_schema -lxmlada_dom -lxmlada_sax -lxmlada_input -lxmlada_unicode -lpthread -L/home/xxxxx/Programs/Development-Tools/GNAT/gnat-collections/db/gnatinspect/obj/ -L/home/xxxxx/Programs/Development-Tools/GNAT/gnat-collections/db/gnatinspect/obj/ -L/opt/ides/gnat/gnat-collections/lib/gnatcoll.static/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_unicode/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_input/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_sax/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_dom/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_schema/ -L/opt/ides/gnat/gprbuild/lib/gpr/static/gpr/ -L/opt/ides/gnat/gnat-collections/lib/gnatcoll_xref.static/ -L/opt/ides/gnat/gnat-collections/lib/gnatcoll_sqlite.static/ -L/opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static/ -L/opt/ides/gnat/gnat-collections/lib/gnatcoll_iconv.static/ -L/usr/lib/gcc/x86_64-linux-gnu/11/adalib/ -shared -lgnarl-11 -lgnat-11 -lutil -lrt -lpthread -ldl -Wl,-rpath-link,/usr/lib/gcc/x86_64-linux-gnu/11//adalib -Wl,-z,origin,-rpath,/usr/lib/x86_64-linux-gnu:$ORIGIN/:/opt/ides/gnat/gnat-collections/lib/gnatcoll.static:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_unicode:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_input:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_sax:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_dom:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_schema:/opt/ides/gnat/gprbuild/lib/gpr/static/gpr:/opt/ides/gnat/gnat-collections/lib/gnatcoll_xref.static:/opt/ides/gnat/gnat-collections/lib/gnatcoll_sqlite.static:/opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static:/opt/ides/gnat/gnat-collections/lib/gnatcoll_iconv.static:/usr/lib/gcc/x86_64-linux-gnu/11/adalib:/usr/lib64:/usr/lib -o gnatinspect
make: *** [Makefile:104: build] Error 4

and the error message for gnatcoll_db2ada is much the same, and is as follows:

gprbuild -p -m --target=x86_64-linux-gnu  -j2 -XLIBRARY_TYPE=static -XXMLADA_BUILD=static -XGPR_BUILD=static -XGNATCOLL_VERSION=0.0 -XBUILD=PROD  gnatcoll_db2ada.gpr
Setup
   [mkdir]        object directory for project GNATCOLL_DB2Ada
Compile
   [Ada]          gnatcoll_db2ada.adb
   [Ada]          gnatcoll-db2ada.ads
   [Ada]          gnatcoll-db2ada-main.adb
Bind
   [gprbind]      gnatcoll_db2ada.bexch
   [Ada]          gnatcoll_db2ada.ali
Link
   [link]         gnatcoll_db2ada.adb
/usr/bin/ld: /opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static/libgnatcoll_sql.a(gnatcoll-sql_impl.o): warning: relocation against `gnatcoll__sql_impl__sql_parameter_characterB3692s' in read-only section `.text'
/usr/bin/ld: /home/brett/Programs/Development-Tools/GNAT/gnat-collections/db/gnatcoll_db2ada/obj/gnatcoll-db2ada-main.o: relocation R_X86_64_PC32 against symbol `system__soft_links__abort_defer' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
gprbuild: link of gnatcoll_db2ada.adb failed
gprbuild: failed command was: /usr/bin/gcc-11 gnatcoll_db2ada.o b__gnatcoll_db2ada.o /home/xxxxx/Programs/Development-Tools/GNAT/gnat-collections/db/gnatcoll_db2ada/obj/gnatcoll-db2ada.o /home/xxxxx/Programs/Development-Tools/GNAT/gnat-collections/db/gnatcoll_db2ada/obj/gnatcoll-db2ada-main.o /opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static/libgnatcoll_sql.a /opt/ides/gnat/gnat-collections/lib/gnatcoll.static/libgnatcoll.a /opt/ides/gnat/gprbuild/lib/gpr/static/gpr/libgpr.a -L/usr/lib/x86_64-linux-gnu/ -lxmlada_schema -lxmlada_dom -lxmlada_sax -lxmlada_input -lxmlada_unicode -L/home/xxxxx/Programs/Development-Tools/GNAT/gnat-collections/db/gnatcoll_db2ada/obj/ -L/home/xxxxx/Programs/Development-Tools/GNAT/gnat-collections/db/gnatcoll_db2ada/obj/ -L/opt/ides/gnat/gnat-collections/lib/gnatcoll.static/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_unicode/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_input/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_sax/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_dom/ -L/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_schema/ -L/opt/ides/gnat/gprbuild/lib/gpr/static/gpr/ -L/opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static/ -L/usr/lib/gcc/x86_64-linux-gnu/11/adalib/ -shared -lgnarl-11 -lgnat-11 -lrt -lpthread -ldl -Wl,-rpath-link,/usr/lib/gcc/x86_64-linux-gnu/11//adalib -Wl,-z,origin,-rpath,/usr/lib/x86_64-linux-gnu:$ORIGIN/:/opt/ides/gnat/gnat-collections/lib/gnatcoll.static:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_unicode:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_input:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_sax:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_dom:/usr/lib/x86_64-linux-gnu/ada/adalib/xmlada_schema:/opt/ides/gnat/gprbuild/lib/gpr/static/gpr:/opt/ides/gnat/gnat-collections/lib/gnatcoll_sql.static:/usr/lib/gcc/x86_64-linux-gnu/11/adalib:/usr/lib64:/usr/lib -o gnatcoll_db2ada
make: *** [Makefile:107: build] Error 4

I have successfully built gnatcoll/sql and so am puzzled as to what I have done wrong.

Even if the documentation contains information on the “FK:” lines for multiple foreign keys (implying tables with multiple PKs), both gnatcoll-sql-inspect.adb and dborm.py fails in some way in these cases.

The reverse relation is not translated from the individual Fks to the multiple “FK:”

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

SQL timestamp is really timestamp without time zone. Instead, it is mapped to timestamp with time zone.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Once built and installed the sql subproject (with relocatable, static-pic and static libraries), it is the turn of postgres and sqlite. But in these cases the binder raises the following message:

   Build Libraries
      [gprlib]       gnatcoll_postgres.lexch
      [bind SAL]     gnatcoll_postgres
   
   raised STORAGE_ERROR : stack overflow or erroneous memory access
gprlib: invocation of /opt/GNAT/2021/bin/gnatbind failed
gprbuild: could not build library for project gnatcoll_postgres
make: *** [Makefile:123: build-relocatable] Error 4

Modifying to an exaggerated degree the process stack size produces the same result.
The only way to proceed is to forget relocatable/static-pic libraries and have only the static one.
So change the makefile.setup to ENABLE_SHARED=no.

The environment was Linux Xubuntu 22.04, GNAT Community 2021 and Postgresql 13.6.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Even if the documentation contains information on the “FK:” lines for multiple foreign keys (implying tables with multiple PKs), both gnatcoll-sql-inspect.adb and dborm.py fails in some way in these cases.

gnatcoll-sql-inspect.adb reads from the SQL database and correctly builds the internal schema. But the final step is to check orphan Fks. This last test fails because the function Get_PK for a table with multiple Pks returns No_Fields.

The solution is to purge such orphan FKDs.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Even if this is a sensible design solution, it should be noted that the length information is lost. Eventually runtime errors may arise.

Gnatcoll-db has the length information of the field. Any way to check at compile time?

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

gnatcoll_all2ada generates type cast for default values, which is redundant.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Autoincrement fields in sqlite are implemented as 64-bit signed integer (see https://www.sqlite.org/autoinc.html) and automatically are primary keys (different from Postgresql where autoincrement fields are not automatically primary key).

They are mapped in the schema to Integer Autoincrement Primary Key (see gnatcoll-sql-sqlite-builder.adb around line 1155), which is correct.

However they are mapped later to Ada Integer instead of Ada Long_Long_Integer. Also in gantcoll-sql-inspec.ads, this has to be changed having its Field_Mapping changed to SQL_Field_Bigint.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Views cannot have primary keys, an error should be reported.

Views with foreign keys must be reported also as errors.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Autoincrement fields (in Postgresql terminology smallserial, serial or bigserial) are mapped in the schema correctly to smallint, integer and bigint. If some of these fields is primary key, it is also correctly marked.

But when extracting the information from the Postgresql database, the autoincrement property is not marked at all in the generated schema.

This situation must be corrected, for example by including a new field property (named Serial) and then set it depending upon the information returned by Postgresql. Obviously the function “is_autoincrement” has to be modified. The python module dborm.py has to be modified too, admitting now in the third column the key “PK,SERIAL” for smallint, integer and bigint.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Debian Sid, gnat-7, gcc-7, gprbuild-2017-5
postgres_sqlite_makes_patch.txt

The function "-" (T : T_Money) return T_Money renames SQL_Impl."-"; was missing.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

The generated code contains procedures to update fields of a table, one by one. It is convenient to have a procedure to update all fields at once.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

I have compiled these components in the past, but today when I tried (have not done it for a while - so did a fetch from git), it fails when I try to build the 'sql' component, which then as this is needed for some of the other components, causes them to fail as well. I have performed a 'make -C sql clean' and then a 'make -C sql setup' before the 'make -C sql'. The make command produces the following error message:

gprbuild -p -m --target=x86_64-linux  -j2 -XGNATCOLL_VERSION=0.0 -XBUILD=PROD  -XLIBRARY_TYPE=static -XXMLADA_BUILD=static -XGPR_BUILD=static \
	gnatcoll_sql.gpr
Compile
   [Ada]          gnatcoll-sql_impl.adb
   [Ada]          gnatcoll-sql-sessions.adb
gnatcoll-sql_impl.adb:1679:44: "UTC_Time_Offset" is not visible (more references follow)
gnatcoll-sql_impl.adb:1679:44: non-visible declaration at a-catizo.ads:28
gnatcoll-sql_impl.adb:1679:44: non-visible declaration at a-calend.ads:403

   compilation of gnatcoll-sql_impl.adb failed

gprbuild: *** compilation phase failed
make: *** [Makefile:116: build-static] Error 4

I am using GNAT 2020 but have also built the git version of gprbuild. Using this produces the same failure. I am presuming that my setup is at fault and would appreciate any help that people are willing to provide.

As it is mapped to timestamp with time zone.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

The constraint error is raised in gnatcoll-sql-inspect.ads. The solution is to move Type_To-SQL to the body.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Default negative numbers such as -5.0 are returned by Postgresql as strings instead of numbers. These strings are qualified by tags such as “::numeric” or “::integer”.

This cause an error in gnatcoll_all2ada.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Passing a Null_Paramter to a prepared statment causes a syntax error in postgresql with anything but textfields.
In the function GNATCOLL.SQL.Postgres.Gnade.Exec_Prepared any Null_Parameter is passed to PQexecPrepared as a string and consequntly gets quoted before being send to the db.
Quick fix i tested:
pass Interfaces.C.Strings.Null_Ptr to PQexecPrepared instead.
Example:
if Params (Integer (P) + Params'First) = Null_Parameter then
Vals (P) := Interfaces.C.Strings.Null_Ptr;
else
Vals (P) := CS.New_String(Params (Integer (P) + Params'First).Image (Format));
end if;
gnatcoll-sql-postgres-gnade.adb.txt

dborm.py generates a routine “from_cache” only for tables with just one PK and integer. This situation must be modified to contemplate the case of just one PK but now smallint, integer, bigint.

Note that gnatcoll-sql-sessions is also affected, in particular the cache part. Even sqlite autoincrement are PKs but with 64 bits, so the actual implementation has this error: change Integer to Long_Long_Integer.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

For example, Postgresql Real type is IEEE 754 Binary32 with a precision of at least 6 decimals, which is equivalent to Ada Float (also IEEE 754 Binary32).

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

In these cases gnatcoll db2ada reports again unknown field types.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

I am getting this trace when trying to insert new data via ORM:

[SQL.ERROR] select failed: SELECT currval('"Comm_Watch_Items"_"Comm_Watch_Item_Id"_seq') PGRES_FATAL_ERROR ERROR: invalid name syntax

Environment: Linux x86_64, GNAT 2017 GPL, XMLAda from Git, libgpr from Git, GNATCOLL from Git (Change-Id: Ia6649032bde129c9ed36e359f2a75ffc2530586a).

Index information is not extracted from the database, therefore no index lines are produced in the schema.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Given that fields are alphabetically classified by gnatcoll_all2ada.

We must assume that the order of fields in the Database is defined by the Database Designer and such order must not be changed.

It is in gnatcoll-sql-postgres-builder.adb procedure For_Each_Field having the clause “ ORDER BY pg_attribute.attname”. Please comment it out.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Note that not all primary keys are autoincrement, so for tables with primary keys that are not autoincrement, there is not way to define a new row, as it is nor possible to assign a value to the primary key field.

The solution is that the functions New_ include parameters for the primary key fields. That implies modifications to dborm.py, which is in python, a surprise as this is Ada generating Ada. In the indicated github path an full Ada solution is included, replacing the python module.

The documentation is also misleading. It is indicated that it is highly recommended to set a primary key on all tables, also recommending using integers for such primary keys for efficiency reasons (i. e. autoincrement). This is not an accurate description: it must say that tables having non-autoincrement primary keys cannot be expanded (using gnatcoll-db) with new rows as the generated Ada code do not include routines to define new rows in these cases.

I have a source code file which contains UTF-8 characters, i.e.: type ℕ is range 1..2**16-1. I normally compile it with the -gnatW8 switch and it works flawlessly, but gnatinspect(1) doesn't generate entities at all.

Hello,
gnatinspect.gpr file is missing in gnatinspect folder.
HTH, Pascal.

Dear contributors,

Following the switch to modular organization, we are working on the testsuite refactoring. Before the testsuite is in place we can't accept pull requests.

We apologize in advance, and thank you for your patience!

In this case gnatcoll db2ada reports unknown field type time without time zone.

For more explanations, you can read the report
https://github.com/fdesp87/gnatcoll-db/examples/mytests/Report.odt

Generating Ada: wrong numeric initialization in dborm.py

Due to the nature of the dborm code, all table names in a model file must be lower-case, otherwise a KeyError will be generated at line 2257 in dborm.py.

Can be reproduced (at least for me) using:

| TABLE | Alpha   | A        || Table A
| id    | INTEGER | PK       || Auto-generated id (aliases rowid)
| data  | TEXT    | NOT NULL || The actual text of table A

| TABLE | Beta       | B        || Table B
| id    | INTEGER    | PK       || Auto-generated id (aliases rowid)
| data  | FK Alpha() | NOT NULL || Just a reference to A

And gnatcoll_db2ada -dbmodel <file_above> -orm ORM.

Which produces a python traceback. Switching the table names to lower case fixes this.

Therefore either the documentation should be updated to reflect this (I'm reading from https://docs.adacore.com/gnatcoll-docs/sql.html where the only description is "name" is the name of the table) or the code should be updated to allow different casings (even just applying a to_lower at the given line should work, though I haven't read enough of the code to verify).

Notes:

I don't have access to the most recent version of gnatcoll, so this could have already been fixed, but the python file in question hasn't changed between these versions and the result can be obtained by directly calling the dborm python script with the appropriate arguments.