Aurelius Swagger Server strange error from model created by TMS Datamodeller

I have used the TMS Datamodeller to produce a set of business object classes for 2 databases.

Both are ElevateDB databases, so somewhat unusual.

In the first case the data-modeller did a really great job. One field-type was wrongly imported as "Variant" instead of "String" I corrected this with find/replace, and I was then able to run SWAGGER-UI tests on the resulting Aurelius server which worked perfectly (so far as I tested).

In the second case (a larger database) quite a lot of the Seagger "GET(ID)" requests return with an error:

 "error": {
    "code": "DatabaseError",
    "message": "Field 'G_ID' not found"
  }

Note that there is no field "G_ID" either in the database, in the Aurelius Classes in the Business Objects PAS file ...

I use a field called "ID" as primary index / key on ALL tables. I don't use Under-score characters anywhere in my schema-names.

Note that the error varies with GET(ID) requests on different Entities.

The "G" becomes other letters such as "F", "K" etc.

I am wondering whether Aurelius is getting confused behind the scenes some how?

Update on this:

I was generating my model using "Association Fetch Model" = Eager.

I have regenerated my model using "Association Fetch Mode" = Lazy and the model now works without any errors I can see (so far)

I am pretty new to Aurelius, so I am not sure whether my original post actually represents a "real" error, I will try to continue to learn how to work with Aurelius using "Lazy" fetch mode and figure things out.

If "Eager" fetch mode should work without error, I can provide more information to help with debugging this ...

Thanks.

The prefixed names like G_ID or F_ID simply means the field name in a big SQL statement. The prefix G or F is the alias of a table.

Since you initially mapped everything as eager mode, Aurelius would try to retrieve all fields from all associated tables in a single SQL statement. So G_ID means it's trying to retrieve the ID field of the table aliased G in the SQL.

It's recommended to map everything as lazy because eager fetching has a limit (3 levels by default) and you can manually turn specific lazy associations into eager for each query you want to execute.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.