Change subject Area to use the OMRS generic handlers

[davidradl]

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?

[davidradl]

I am thinking that I may not need to redo the existing subject area generics and could go straight to the omrs generics helper.

[davidradl]

I have initial implementations for add , update, delete and get for each of the nodes.

• for restore, there are no generic handler methods I could find. I am thinking it should as much as possible try to undo what the delete did.

Nodes

• if the restore is for a Term or Category only restore if the glossary is active - otherwise error.
• if the restore is for a Term or Category that is itself an anchor -for example if it has comments. Then the anchored content should be restored.
• For directly connected deleted, non anchored relationships to active entities. For example if there was a has-a relationship to a parent term, it seems reasonable I restore this.
• restore should update the latestChange like update does
• restore should restore all associated deleted classifications (which may be more that were there at delete time).
• restore should add in spine object classifications and anchor and latestchange classifications as appropriate

• if the restore is for a glossary then we should restore

  • any deleted classifications, and deleted relationships to active entities
    • any deleted anchored content including any deleted classifications, and deleted relationships to active entities

  Relationships
  Only restore if both ends are active.

  • for a deletion of a has-a relationship - I am thinking we should remove the spine attribute and optionally the spine object (if it is the last has-a) and then the restore should put them back.

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

[davidradl]

Updated https://github.com/odpi/egeria/issues/5465 to include the cponsideration of restores around TermAnchors, which delete the Term.