...
...
Decisions
# | Description | Details | Decisions |
|---|---|---|---|
| 1 |
CPS Persistence SPI
https://github.com/Ericsson/cps-persistence-spi/tree/spi-docs/docs/dps-core-spi
...
Assume flat attributes (no complex data types) but data could be stored as json object in SPI impl. for convenience/PoC | |||
| 2 | SPI should be type safe (the SPI impl. has no access to models)
|
Open Issues
# | Description | Details | Decisions |
|---|---|---|---|
| 1 | SPI Imp NOT using Model (service) current ENM SPI does! | ||
| 2 | the current SPI builds restrictions and has special methods to combine them. Having a fluent interface in my opinion would be way more intuitive and practical. E.g. //AND of two restrictions Restriction and(Restriction firstRestriction, Restriction secondRestriction) //OR of two restrictions Restriction or(Restriction firstRestriction, Restriction secondRestriction) //NOT of a restriction Restriction not(Restriction restriction) This will give any user of the API an intuitive way to build a complex query and the developer of the API a tree to navigate and translate to SQL (or any other query language). A developer could do something the likes of myQuery.setRestriction(restriction1.and(restrcition2).and(restriction3)) |
Link to ENM SPI
Link to the SPI can be found here: https://github.com/Ericsson/cps-persistence-spi/tree/spi-docs/docs/dps-core-spi
High level structure of ENM SPI
This SPI implementation is towards neo4j. The SPI depends on the DPS API and the model service API.
It can be used as a source of ‘inspiration’ however it is important to realize that the SPI implementation was ‘model’ aware - used models heavily to optimize the queries. The SPI implementation also makes a choice of breaking down models to nodes based on MO type and flatten CDTs as properties within the node. There is no concept of MO type or CDTs in Yang so we cannot reuse the same idea.
Query SPI
Path - cps-persistence-spi-spi-docs\docs\dps-core-spi\com\ericsson\oss\itpf\datalayer\dps\query\spi
...