CPS-1177 - Getting issue details... STATUS
Description/Scope
There are 3 datastore related endpoints exists on the proxy controller.
- /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-operational:
- $ref: 'ncmp.yml#/getResourceDataForPassthroughOperational'
- /v1/ch/{cm-handle}/data/ds/ncmp-datastores:operational:
- $ref: 'ncmp.yml#/getResourceDataOperational'
- /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running:
- $ref: 'ncmp.yml#/resourceDataForPassthroughRunning'
Parameters used by each endpoint
| Endpoints/Params | datastoreName | cmHandleInPath | resourceIdentifierInQuery | optionsParamInQuery | topicParamInQuery | includeDescendantsOptionInQuery |
|---|---|---|---|---|---|---|
/v1/ch/{cm-handle}/data/ds/ ncmp-datastore:passthrough-operational |  | | | | | |
/v1/ch/{cm-handle}/data/ds/ ncmp-datastores:operational | | | | | ||
/v1/ch/{cm-handle}/data/ds/ ncmp-datastore:passthrough-running | | | | | |
It would be better to have just one handling all the cases like /v1/ch/{cm-handle}/data/ds/{ncmp-datastore-name}
where {ncmp-datastore-name} can be set to ncmp-datastore:operational or ncmp-datastore:passthrough-operational or ncmp-datastore:passthrough-running
Open questions
| # | Question/Issue | Decision/Notes |
|---|---|---|
| 1 | If want to have full backward compatibility than we will have ':' in the URL, alternative way: just remove "ncmp-datastore:" prefix | Its not problem as it is more important to stay backward compatible |
Proposed solutions
Use just a switch to execute the appropriate function from the old functions
Use Factory pattern alone
Use Builder pattern to set config for the Factory (Thanks Andras for the idea)
Make handler Builder (Solution will be proposed by Andras)
Advantages and Disadvantages of Proposed Solutions
Advantages and Disadvantages of the simple switch
| Advantages | Disadvantages |
|---|---|
| Really easy to understand cos one can clearly see the switch and the original endpoint functions | Hard to see the common parts |
| Easy to maintain | If the parameters of any original function change you have to change the new one also |
| Not that elegant |
Advantages and Disadvantages of the Factory Pattern
| Advantages | Disadvantages |
|---|---|
| Easy to understand by look | It cannot be a classic Factory because of the common services and constants used in the logic of the handlers |
| All the business logic is abstracted away (switch and the handlers) | Factory has a constructor because of the common services and constants used in the logic of the handlers |
| The business logic of the handlers are in their own Handler class | Handlers has many parameters because of the different parameter list used by the original endpoints |
Advantages and Disadvantages of the Builder Pattern and Factory used together
| Advantages | Disadvantages |
|---|---|
| All the advantages of Factor pattern solution | All the disadvantages of Factor pattern solution |
| The user can clearly see which parameter has been set to which value on the constructor of the Factory | One more layer of abstraction |
Advantages and Disadvantages of the Handler Builder
| Advantages | Disadvantages |
|---|---|
| All the advantages of the Builder Pattern and Factory used together | All the disadvantages of the Builder Pattern and Factory used together |
| No factory is needed the handle function will be reused from the above | Not really a builder nor a Factory so maybe a bit hard to grasp at first |
Decision & Rationale
The number 4 will be implemented which is mix of Builder and Factory