mandy-chessell
commented
1 year ago I had a look that the repository services (OMRS) and the graph repository:
- The default value of classificationOrigin is null.
- The graph repository does not save or restore this value.
- Many test cases leave this value null.
- The repository helper/archive helper methods do not set it.
So XTDB will see this issue from many sources. Egeria PR https://github.com/odpi/egeria/pull/7631 changes the default value of of classificationOrigin to ClassificationOrigin.ASSIGNED. This should mean that XTDB running in an Egeria platform that includes this fix will not see null unless the caller explicitly sets it to null.
I was doing some testing on 4.1 with XTDB and noticed a lot of errors and some exceptions in the console log so to try to establish a baseline, I reverted to 4.0 and tried some simpler configurations and tests.
Using the lab jupyter notebooks, I configured cocoMDS1 to be xtdb-inmemory and left the others with the default. I then ran building a catalog and it ran without any issues or errors in the log.
I then started the Working-with-standard-models. I started to see errors pretty quickly in the logs. 100s were of the form:
Wed Apr 26 02:04:08 GMT 2023 cocoMDS1 Error OMRS-XTDB-REPOSITORY-0022 The requested ClassificationOrigin enumeration with ordinal or symbolic name null does not exist.From the lab perspective the import of the CIM glossary appeared to work and the subsequent calls worked (but perhaps they were going to a cohort member). There was no indication of a problem. I was able to create a new glossary and a new term and then return it without issue. However when I tried to update the term I just created it gave me a 404 not found error for some reason.
I suspect that more testing is needed - but I wanted to at least start to establish a stable baseline...
Thoughts? egeria4.0-xtdb-inmemory-4-25d-asset.log