OMAG-REPOSITORY-HANDLER-404-018 Method updateSchemaAttribute for service Data Manager OMAS is not supported by any of the metadata repositories connected to {mds-server} #457
Comments
|
@mandy-chessell can you help troubleshoot this one? Looks like an error being thrown by the OMAS — hoping you might have an idea what method(s) it would be trying to call on the underlying repository that would be new / changed and thus not (yet) available in XTDB repository... (Or is there a chance that this is a configuration issue where the OMAS hasn't first been stood up somewhere, since |
|
@cmgrote I suspect it is caused by the new classification methods not being implemented - a look at the console log would confirm it. @juergenhemelt could you supply details of the version of the XTDB connector that you are running and also the other messages logged on the console around the same time. |
|
This is an excerpt of the audit log of the calling integration connector: Hope this helps. |
|
Sorry, I was not clear - we need the audit log from the metadata server where XTDB is located. |
|
Here it is: |
|
Interesting — looks like I missed the separate update method for an entity proxy... Will add it to my backlog. |
|
Actually looks like multiple new methods I missed:
@mandy-chessell — in case there are any others that jump to mind that I might have missed? 🙏 |
|
@mandy-chessell Am I correct to assume that the expected behavior of Looking at the in-memory repository implementation there seems to be different behavior between the two methods:
^^ Just want to confirm that's intentional? |
|
Simple answer is yes (if the repository is saving reference copies of that type). So if only the entity proxy is passed (as in the new methods) then if the repo wants to save the classification, it saves the entity proxy first to provide an attachment point for the classification. The reason we needed the new methods stems from the lack of OMRS events from IGC. This meant that no reference copies for IGC metadata were saved in any other member of the cohort. It was not safe to push the reference copy of the entity via the enterprise connector because the lack of a delete event from IGC could resulted in entities being returned after they had been deleted. Without reference copies, we could not save new classifications in these other repositories for IGC entities because the reference copy for the entity was not available. We needed to be able to save the entity proxy so we could attach the classification to it. (Entity proxies are ok to save because they are not retrieved by getEntityDetail()). Unfortunately, this then required new OMRS event types to send details of the new classification passing the entity proxy rather than the entity detail (which of course is not available.) |
Implements new classification methods for #457
|
These methods should all be implemented now in the latest snapshot. I've also run them through the CTS (locally), but I'm not sure that we have test coverage of them yet judging by the @juergenhemelt any chance you'd be open to retrying your tests with the latest snapshot build here? I just want to have some level of confidence this has actually solved the problem before I cut the release 🙏 You can download the jar file containing the current latest build directly from this URL: https://oss.sonatype.org/content/repositories/snapshots/org/odpi/egeria/egeria-connector-xtdb/3.15-SNAPSHOT/egeria-connector-xtdb-3.15-20230212.225744-2-jar-with-dependencies.jar |
|
@cmgrote do you have getHomeClassifications implemented? This was added to retrieve the classifications homed in a different repository to the entity |
|
@cmgrote I downloaded and installed the JAR. After a restart of the platform the exceptions do not appear any more. So looks good from my site 👍 |
Yes, |
I get the above exception when calling
TopicIntegratorContext.updateSchemaAttributewhen using a metadata repository server with XTDB connector.The text was updated successfully, but these errors were encountered: