Closed davidradl closed 3 years ago
I am thinking that I may not need to redo the existing subject area generics and could go straight to the omrs generics helper.
I have initial implementations for add , update, delete and get for each of the nodes.
Nodes
if the restore is for a glossary then we should restore
Relationships
Only restore if both ends are active.
@mandy-chessell @cmgrote @planetf1 @lpalashevski Let me know if there is existing logic or your thoughts on this .
Update after community meeting on 6th of July This issue will implement a minimal restore. https://github.com/odpi/egeria/issues/5465 implements new more sophisticated restore logic in the generic handlers.
Updated https://github.com/odpi/egeria/issues/5465 to include the cponsideration of restores around TermAnchors, which delete the Term.
I am considering moving over to use the generic handlers for the Subject Area, as I was looking to extend to re use code in in the generic handlers for this fix. I then pickup the anchor classifications and visibility logic. Also the jsonld parser will now create these classifications when using the subject area OMAS API
My proposal is that :
I change the code to call GlossaryHandler GlossaryBuilder GlossaryCategoryBuilder GlossaryCategoryHandler GlossaryTermBuilder and GlossaryTermHandler. This would work for add, update, read, find I then need to amend my mappers to map the beans to the OMAS I still need logic could deletes and replace/update in the omas code. I want to reject delete requests of glossaries with content. Additional handler content
I need to extend the omrs handler to include get/find category terms , category children, glossary terms, glossary categories and terms categorizations. All with filters and regex flags. I need to consider what this means for the relationship APIs I need to consider what this means for the graph API. getEntityNeighbourhood. @mandy-chessell @cmgrote @planetf1 does this sound right or have I misunderstood / missed something?