Re: [Edgex-tsc-core] Core Contract Model Validators
On 4/4/19 3:39 PM, Malini Bhandaru wrote:
Thanks for the reply Malini!
That's what we were discussing during our call today. The original problem was that a received JSON model was missing a required field. Trevor's branches both make the call to Validate in the UnmarshallJSON methods of our models. So when any of our services handle incoming REST calls with JSON payloads, the service calls json.Unmarshall, which in turn causes the UnmarshallJSON method of the top-level model, and all of it's children to be called recursively. The problem is that since Validate is called by each model's UnmarshallJSON method, you can end up with Validate being called more than once for some of the embedded models. My suggestion to call validate *after* the json.Unmarshall call was an alternative to adding a "valid" flag to each model in order to reduce the duplicate calls.
All that said, there's nothing that would prevent
our services (or unit tests) from using Validate() in other
areas of the code...
Unfortunately Go doesn't provide traditional OO inheritance, meaning there's no concept of base classes. Your analogy is correct though, with this addition, our services would validate REST input (CBOR or JSON instead of HTML forms) before doing anything with the resulting models.
Actually this proposal allows each model to decide what is required in order for the model to be considered valid. The original bug was that a provisionwatcher was received and it lacked an "OperatingState". With this approach, the OperatingState Validate() method would return an error as since one wasn't received in the JSON, the OperatingState isn't set to one of the two allowed values ("Enabled" or "Disabled").
We had a long discussion about the merits of gRPC during our original design discussions about binary data support. In the end, we decided to go with a new serialization format (CBOR), but keep REST as the default mechanism for cross-service communications.
Note - JSON also supports schemas, and we
discussed the merits of using a schema validation vs. an Go
interface-based approach, and it was felt the latter was a