CCSDK-2872 DP: Agree and document proposed long-term Persistence SPI(s)
Jira Ticket:
CPS-37: DP: Agree and document proposed long-term Persistence SPI(s)Closed
Decisions/Open Issues
Decoupling
It is very important that the SPI doesn't expose any database implementation for example database ID's
Description | Details | Decisions | |
---|---|---|---|
1 | Assume flat attributes (no complex data types) but data could be stored as json object in SPI impl. for convenience/PoC | ||
2 | SPI Implementation NOT using Model (service) current ENM SPI does! | ||
3 | Are we going to have XPath/query builder? |
| |
4 | When do we get attributes? | How do control how many attributes we get back? | We will have an (optional) output specification with the following options
|
5 | Should we use the name node or fragment? | We decided on the name DataNode | |
6 | Do we want to split the interface? | Maybe we could just have a 3 Alternatives
|
The above will be in separate maven modules. Any data object they need will be in the same module. We will not have a querybuilder in SPI but the SPI will have to understand the cpsPath. The java API will use a builder pattern to create a cpsPath |
7 | Do we need objects for very simple concept like dataspaceName which are just a string? |
| |
8 | Should we share common objects between the Java API and SPI? | Alternatives
|
ENM SPI Study
Details about the ENM SPI can be found here: ENM Study
Interface Proposal
can be found at : Interface Proposal for CPS
Proposed Future Implementation of CPS SPI
DataStore SPI
Name | Capabilities | |
---|---|---|
1 | DataStoreService |
|
2 | DataNode Object |
|
CpsAdmin SPI
Name | Capabilities | |
---|---|---|
1 | CpsAdminService |
|
2 | DataspacePersistenceService |
|
3 | AnchorPersistenceService |
|
4 | Dataspace (object) |
|
5 | Anchor Object |
|
Module SPI
Name | Capabilities | |
---|---|---|
1 | ModuleStoreService |
|
2 | ModulePersistenceService |
|
3 | YangModule |
|
4 | ModuleRef |
|
5 | ModuleSet |
|