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

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?

  • We should decide based on what the users want to use/is easy to use

  • We don't want a query builder that eventually mimics XPaths functionality, use what is defined already XPATH as a based but maybe supplement with a xpath-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

  1. Default is no attributes 

  2. All Attributes

  3. Specify attributes - output specification (filter)

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 

  1. all in one interface

  2. Limited number of interfaces e.g Data Objects/ Data Persistence/Query

  3. Very fine grained (see below)

  1. DataStore SPI - methods to add data. 
    e.g dataStore.addChild(parentDataObject, childDataObject)

  2. CpsAdmin Interface will handle the dataspaces and anchors

  3. Module SPI - responsible for handling modules and module sets

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?



  • We will not use objects for name fields. We will just use Strings.

  • We may need an object for AnchorName

8

Should we share common objects between the Java API and SPI?

Alternatives

  1. API depends on model objects defined in SPI

  2. SPI depends on model objects defined in API

  3. Extract common model API in separate module (deliverable)

  4. Use separate models with slightly different names e.g Anchor in API and AnchorDetails in SPI (CPService will transfer when needed)



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

Name



 Capabilities

1

DataStoreService

  • String addDataNode(String dataspaceName, String anchorName, DataNode dataNode);

  • String addDataNode(String dataspaceName, String anchorName, String xPath, DataNode dataNode);​

  • String getCpsPath(String dataspaceName, String anchorName, DataNode dataNode);

  • String getCpsPath(String dataspaceName, String anchorName, DataNode dataNode);

  • DataNode getDataNode(String dataspaceName, String anchorName, String xPathId);

  • Collection<DataNode> queryDataNodes(String dataspaceName, String anchorName, String cpsPath);

  • Collection<DataNode> queryDataNodes(String dataspaceName, String anchorName, String cpsPath, String outputSpecification);

  • Integer count(String dataspaceName, String anchorName, String cpsPath);

  • Integer count(String dataspaceName, String cpsPath);

  • void updateDataNode(String dataspaceName, String anchorName, DataNode dataNode);

  • void setLeaf(String dataspaceName, String anchorName, String xPathId, String leafName, Object leafValue);

  • Void deleteDataNode(String dataspaceName, String anchorName, String xPathId);

2

DataNode Object

  • DataNode createDataNode(DataNode)

  • String getCpsPath()

  • DataNode getAttributes()

  • DataNode getAttribute(name)

  • Void setAttributes()

  • Void setAttribute(name)

  • Module getModule(moduleName)

CpsAdmin SPI

Name



 Capabilities

Name



 Capabilities

1

CpsAdminService

  • String createDataspace(String dataspaceName);

  • String createAnchor(String dataspaceName, String anchorName);

  • List<String> getDataspaces();

  • Collection<Anchor> getAnchors(String dataspaceName);

  • Anchor getAnchor(String dataspaceName, String anchorName);

  • void deleteAnchor(String dataspaceName, String anchorName);

  • void associateAnchorToModuleSet(String dataspaceName, String moduleSetName, String anchorName);

  • boolean exists(String dataspaceName);

2

DataspacePersistenceService



  • Void createDataspace(dataspaceName)

  • Void getDataspace(dataspaceName)

  • Void getDataspaces()

  • boolean exists(dataspaceName)

3

AnchorPersistenceService

  • Void createAnchor(dataspaceName, anchorName)

  • Anchor getAnchors()

  • Anchor getAnchor(anchorName)

  • Void deleteAnchor(anchorName)

  • Void associateAnchor(anchorName, moduleSetName)

  • Void associateAnchor(anchorName, moduleRef)

  • Void addDataNode(anchorName, dataNode)

4

Dataspace (object)

  • Void createDataspace(dataspaceName)

  • String getName(Dataspace)

5

Anchor Object

  • Void createAnchor(anchorName)

  • String getName(Anchor)

Module SPI

Name



 Capabilities

Name



 Capabilities

1

ModuleStoreService

  • Collection<String> getModules(String dataspaceName, String moduleSetName);

  • Collection<ModuleRef> getModuleRefs(String dataspaceName, String moduleSetName);

  • Void deleteModuleSet(String dataspaceName, String moduleSetName);

2

ModulePersistenceService



  • YangModule getModule(moduleRef)

  • Collection<YangModule> getModules(moduleSetName)

3

YangModule

  • ModuleRef getModuleRef(moduleRef)

  • String getModuleContent(moduleRef)

4

ModuleRef

  • String getNamespace(moduleRef)

  • String getRevision(moduleRef)

5

ModuleSet

  • String getName(moduleRef)

  • Collection<ModuleRef> getModuleRefs()



Javadoc