You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

CPS-322 - Getting issue details... STATUS

Currently there is no validation within CPS for names/ID's. Meaning that there is no restrictions to what the following can be named

  • Dataspaces
  • Schema-Sets
  • Anchors
  • CM-handles
  • CM-Handle Properties.

Open Issues

#Questions/Open IssuesNotesDecisions
1What kind of naming validation should be in place?

According to this ONAP Documentation it should be alphanumeric with underscores(_) VNF and PNF Modeling Requirements - Resource IDs

We have currently decided to follow this approach, and add any extra characters as seen fit.
2

Should CM-Handle ID's be more strict, or carry the same amount of strictness as anchor names. Due to the fact that we create a corresponding anchor for every CM-Handle it cannot be less strict.

As part of this commit, we can modify the code so anchor creation will happen for the cm handle registration. So if it fails the validation at this point, the CM-Handle will not be registered.Still yet to commit to a decision on this currently.
3

Should validation also be applied to Get/Query API's as opposed to just creation of the functions above? 

Not recommended as this will add little value, at a high costHave decided not to implement this currently.
4Should dashes be included?A lot of dummy data and tests within CPS use dashes as part of their Network Function ID's. If we decide to not use dashes, we should also change these.Have not made a decision on this yet. Will need a team consensus. 

Implementation Proposals

At CPS's service layer within the the Java API:

  • Using general the Java util regex package  and libraries for String validation using plain old java code.
  • Use Spring validator at service level for java API's for CPS-Core, along with javax's constraint package.
  • Use open api's pattern keyword for parameters passed for the cm-handle id's as part of cm-handle registration.
  • Use Apache's validation library, specifically the regex validator class as part of this library.
  • Throw Data Validation Exception(BAD_REQUEST 400 Error Code) on invalid ID's.
  • If same rules apply for anchor as CM-Handle ID, throw the exception when creating the anchor (Current code will have to be refactored to accomplish this, as CM-Handle is registered before Anchor is created).
  • Or, CPS-Core will expose a new java interface to check if anchor name is valid when registering a CM-Handle.

Pros/Cons

ImplementationProsCons
Java Util Package
  • More consistent use of code from this library across CPS
  • Easier to write individual unit tests for.
  • Can throw more specific error message if validation doesn't match.
  • More production code
Spring/OpenApi keyword
  • Less production code
  • Inconsistent use of one validation library across code.
  • Harder to write individual unit tests for.
Apache Commons Validator

  • No labels