How best to deal with (discover) miss-typed fields across schema.json and a go struct

[fils]

So this question comes from an error I did with relation to code: https://github.com/OpenCoreData/ocdGarden/blob/master/frictionlessdata/ocdFricTest1/main.go and schema.json file: https://github.com/OpenCoreData/ocdGarden/blob/master/frictionlessdata/ocdFricTest1/schema.json

I have a simple struct at the top of the code that can look like this.

type chemicalCarbon struct {
    Leg        string
    Site       string
    Hole       string
    Depth_mbsf int
}

Note the type of "Leg" in this case is not the same as the type in the schema.json. This code runs fine, but will result in an empty output file. (which is better than writing the bad data). A fmt.Print will show {Ð 1262 C 90}.

It would be nice to catch this type mismatch programmatically and I was curious if there was a suggested best practice or code snippet for validating struct types against schema.json. Obviously we can't guarantee order or naming of fields, so would seem one would have to align and test the fields explicitly somehow.

Ideas.. suggestions... guidance welcome...

[danielfireman]

Hi @fils

Note the type of "Leg" in this case is not the same as the type in the schema.json. This code runs fine, but will result in an empty output file. (which is better than writing the bad data). A fmt.Print will show {Ð 1262 C 90}.

The empty file must not happen. It should be either an error or print some "good enough" result. Did update your code and capture/print the error returned by DecodeTable? Could you please answer this thread with the result?

It would be nice to catch this type mismatch programmatically and I was curious if there was a suggested best practice or code snippet for validating struct types against schema.json.

Check errors from Encode/Decode is the best. As stated in the documentation, if the value cannot be encoded/decoded to/from the struct and error must be returned (and it is). Please notice that constraints can also be in place and Encode will fail if those constraints are not met.

Obviously we can't guarantee order or naming of fields, so would seem one would have to align and test the fields explicitly somehow.

This alignment and guarantees are already happening. My last commit makes decoding order consistent (using schema declaration order) and the match is based on field name or struct tags (not related to ordering). For encoding, the match is based on the field name or specific struct tags (this was a recent contribution). Examples are updated.

[fils]

@danielfireman sorry for the confusion.. it was TOTALLY me being sloppy. Using _ for error is always wrong ;)

your code is trapping the type error as I would expect and I can use that to trap out error prior to writing the file.

THANKS!

[danielfireman]

Cool! Thank you for being an early adopter of the library, questions and bug reports!!