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