That method looks to be working off raw JSON where the method I suggest is on the object, not the JSON. But this isn’t needed if you can get the “remove the omitEmpty tag” working. BTW, I

Hi all -- I wanted to follow up on this discussion we've been having in the Core Working Group about validating our contract models and where that responsibility lies. This past week we talked about

Another update on this – This week in the #core channel on Slack Ian Johnson asked me why the approach below didn’t involve creating a Validator interface and using reflection to go through

I did a bit of research on this and there's been at least one formal golang proposal to enhance the JSON annotation language to cover missing fields:

An alternate/simpler approach to that solves the duplicate validation calls problem is just to make validation a responsibility of the original caller (ie. the function/method

Thank you Trevor for the links! Shall check them out. Am I correct in assuming that the validator will be invoked at the recipient endpoint of a rest call, and only then? Then we could as part of

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

Thanks for providing that summary Tony. I've been working on incorporating the "is validated" discussion from this morning into the feature branches below. There's a problem in that we have types

+1 from me to continue on this approach Feel free to also add me as a reviewer when you're ready - I've written some go reflection code for a few different projects.

+1 from me also.

I *think* what you're saying here is that if we changed the UnmarshallJSON() functions to call <model>.Validate() in adminstate.go and operatingstate.go, then we have the same problem

Hi Tony – An issue with the sample code in your branch is that Addressable must make a call to a.Validate() on line 179 instead of returning nil. This is because there are other endpoints that take

Then the other endpoints just need to call Validate(). So this branch is yet another approach to the same problem? Sorry if I'm being dense here? This looks like you've added validation

We’re talking in circles now. If you want to have a call, let me know but I have to start working on this. Trevor

Just to update everyone on the thread, I just talked with Tony and we’re on the same page. We will be taking the reflection-based approach with the IsValidated() check for complex types. Trevor

Hi all -- During today's Core Working Group call as we were discussing various ways for export-distro / app-functions-sdk to notify core-data that an event had been successfully handled, I believe

Hello all, Last week during the Core Working Group call we were discussing a couple of ways to address some issues regarding capturing ID and time information when dealing with CBOR content in

Yes, this is very helpful to see the metrics we can anticipate for re-encode, garbage collection, and memory utilization. Thank you Anthony! Are the timings you measured for re-encode in units of

I had inadvertently recorded a timing for the last cell in the timings as7m36s. This resulted from my run of5000 iterations on the final check, in attempt to smooth out noise on average timings

Hi all -- As you're aware from recent working group calls we need to develop a mechanism whereby the service configurations can be easily overridden to use Redis for the upcoming Edinburgh release.