Jira Ticket:
- CPS-37Getting issue details... STATUS
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 |
ENM SPI Study
Details about the ENM SPI can be found here: Spike
Proposed Future Implementation of CPS SPI
DataStore SPI
Name | Definition | Capabilities | |
---|---|---|---|
1 | DataStoreService | Provides the basic information needed to access an object. |
|
2 | DataNode Object |
|
CpsAdmin SPI
Name | Definition | Capabilities | |
---|---|---|---|
1 | DataspacePersistenceService |
| |
2 | AnchorPersistenceService |
| |
3 | Dataspace Object |
| |
4 | Anchor Object |
|
Module SPI
Name | Definition | Capabilities | |
---|---|---|---|
1 | ModulePersistenceService | Adding functionality for handling attributes |
|
2 | BasicModuleObject | Create a simple CPS Module Object |
|