Resources
- CPS-235 - Getting issue details... STATUS
Updates
| Slogan | Jira | Notes | Priority / When do we need this? | |
|---|---|---|---|---|
| 1 | Replace DataNode(tree) | CPS-58 - Getting issue details... STATUS | This is powerful update method that can fulfill all below scenarios too. However it is a crude and inefficient for scenario with children. Ada a child at the top of the tree will required the client to re-submit all existing data of the siblings and their descendants. replacing all of them in the DB layer which of course could lead to very lengthy update operations. | Already being implemented. Need to investigate if E2E Slicing requires the 'with descendants' option |
| 2 | Update Single attribute on single DataNode | Done | Client provides on full xpath and single attribute and value. Internal it might required to get the target node form the DB, update and then validate | Probably required for E2E Slicing |
| 3 | Update Multiple attributes on single DataNode | Done | This could a simple extension of the previous method (#2) by instead of providing one key-value pair it could be map of many. Question remains if we ant to Java-API methods, or one. And if just it could be handled by one user story instead, depending on team preference | |
| 4 | Add Child DataNode | CPS-337 - Getting issue details... STATUS | should be possible to add node with just the data for the new node (which includes a full xpath so that the parent an be identified) further descendant can easily be included (should not require additional work ie. separate user story) | Investigate if needed for E2E Slicing. But seems likely this is needed soon and to address the technical debt of the solution in #1 |
| 5 | Add DataNode to List | CPS-360 - Getting issue details... STATUS | should be possible to add node with just the data for the new node (which includes a full xpath so that the parent an be identified) question: should the xpath for the list entry be generated (using the model and keyfield(s) data) or included in the dat provided by the client | Investigate if needed for E2E Slicing. But seems likely this is needed soon and to address the technical debt of the solution in #1 |
| 6 | Remove DataNode | Assume this will also cover removing DataNode from a list | Investigate if needed for E2E Slicing. But seems likely this is needed soon and to address the technical debt of the solution in #1 | |
| 7 | Add element to Leaf-List | Nice-to-have. From experience in similar project this use-case never was prioritized. It can always be done using #3 or #4 instead. My recommendation is to not consider this until a client specially requests it and argues the need for it. | ||
| 8 | Remove Element from Leaf-List | Nice-to-have. From experience in similar project this use-case never was prioritized. It can always be done using #3 or #4 instead. My recommendation is to not consider this until a client specially requests it and argues the need for it. |