Jira |
---|
server | ONAP Jira |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | CPS-791 |
---|
|
OverviewIn a spring application, we usually have three layers and each layer have a different responsibility.
- Web Layer (Controller, Exception handler, Mappers) - receive the request and send the response to the client.
- Service Layer - Business logic
- Repository Layer (Repository Interfaces & custom Repositories) - DB interaction at the lowest level
CPS have four layers of architecture and the 'Persistence Layer' was introduced to have loose coupling with DB. It gives an ability to move to another type of DB with little change.
...
The current implementation for of the persistence service Persistence Service SPI is provided in 'cps-ri' which is specific to relational DB. If we want to use another type of DB later, the Persistence and Repository layer needs to be re-written. To achieve the original intent (use a different DB type later)Therefore, it is important to keep the business logic in the 'Service' layer and have only database-specific logic in the 'Persistence' layer.
...
In the existing implementation, the 'Admin Service' and 'Module Service' have the implementation to delete Data Node which is managed by 'Data Service'. This behaviour is not expected as 'Data Service' is responsible for deleting DataNode and should control how it can be done. The other services should utilize this functionality from DataService wherever required.
As a part of In this proposal, the business logic
Delete Anchor
the business logic of the 'Delete SchemaSet' and 'Delete Anchor' functionality will be moved to Service Layer and domain-specific services will be used to do any operation of the domain objects.
Delete Anchor
When an anchor gets deleted, all the associated data nodes should get deleted too. The suggestion is to use DataService to delete the data nodes instead of using Fragment Repository directly.
draw.io Diagram |
---|
border | true |
---|
| |
---|
diagramName | Existing Delete Anchor Sequence Diagram |
---|
simpleViewer | false |
---|
width | 600 |
---|
links | auto |
---|
tbstyle | top |
---|
lbox | true |
---|
diagramWidth | 629 |
---|
revision | 2 |
---|
|
draw.io Diagram |
---|
border | true |
---|
| |
---|
diagramName | Proposed Delete Anchor Sequence Diagram |
---|
simpleViewer | false |
---|
width | 600 |
---|
links | auto |
---|
tbstyle | top |
---|
lbox | true |
---|
diagramWidth | 629 |
---|
revision | 2 |
---|
|
Delete Schema Set
Schemaset contains the model against which the anchor data nodes are validated. So, when a schema set is deleted, the logic to validate if associated anchors exist and whether it can be deleted is business logic and should be in the Service layer.
Code Block |
---|
title | Delete SchemaSet Business Logic |
---|
linenumbers | true |
---|
|
DELETE SCHEMASET( dataspaceName, schemaSetName, cascadedAllowed)
anchors = CALL Get Anchors associated with Schema Set ( dataspaceName, SchemaSetName )
IF Cascade is Prohibited & anchors exists
throw exception
END IF
Delete associated anchors if casacade allowed
Delete SchemaSet
END |
draw.io Diagram |
---|
border | true |
---|
| |
---|
diagramName | Existing Delete Schema Set |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | top |
---|
lbox | true |
---|
diagramWidth | 688 |
---|
revision | 2 |
---|
|
draw.io Diagram |
---|
border | true |
---|
| |
---|
diagramName | Proposed Delete Schema Set |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | top |
---|
lbox | true |
---|
diagramWidth | 688 |
---|
revision | 2 |
---|
|
...