Ian makes a good point in that in the non-docker scenarios, the configuration.toml is easily modified to specify use of Redis. So in those cases having a new command line switch is redundant. I

Apologies for the long email, but there's a bit of background necessary to explain why I don't think it's a good idea to use this command line flag in the snap. With the snap we are in a better

I prefer PR 1348 as it works for native and snaps, not just Docker. Also, I think it is more straight forward than modifying the toml file during the Docker build. -Lenny

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.

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

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

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

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

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

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

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

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

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

+1 from me also.

+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.

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

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

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

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

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: