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

Compare with Current View Page History

« Previous Version 15 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.

Regex Pattern 
^[a-zA-Z0-9_]*$
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.
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.
5Implementation approach for validationWe have discussed 3 possible libraries for implementing this validation. These include java's util library, spring validator at the service level of CPS, along with using open api's 'keyword' for dealing with CM-Handle ID validation, or using apache commons validation regex library.
6The validation logic with the regex should be implemented in a separate utility class.A new common utility class should be created specifically for regex validation as part of this user story.

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 commons regex 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

Implementation ApproachProsCons
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
  • Similar to Java Util Library.
  • Adding extra dependency for no further advantage.
  • No labels