Change subject Area to use the OMRS generic handlers

[davidradl]

No description provided.

[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. #5465 implements new more sophisticated restore logic in the generic handlers.

[davidradl]

Updated #5465 to include the cponsideration of restores around TermAnchors, which delete the Term.