Re: Zephyr JSON API can't find missing fields in sub-objects

Leandro Pereira


On 05/02/2017 10:07 PM, Marti Bolivar wrote:

However, when I parse this, I can tell whether "config" or "_links" is
present in the top-level JSON object using the return value from
json_obj_parse(), but I can't tell if its subobjects (the
"deploymentBase", "cancelAction" etc. in "_links") are present or not.
That's indeed a known limitation.

One way to do this would be to introduce a u32_t in each structure
(hawkbit_ctl_res_sleep, hawkbit_ctl_res_polling, hawkbit_ctl_res_href,
hawkbit_ctl_res_links) recording whether or not each of the "real"
fields is present, and have the JSON API fill this value recursively
as it parses. This would let me decide what fields are present at all
levels in the parsed hierarchy.

Does this seem reasonable? Does anyone else have other suggestions?
In this case, it might be sufficient to zero out the struct hawkbit_ctl_res struct, and then just NULL-check _links.cancelAction.href or _links.deploymentBase.href. It's not the ideal generic solution but will work for strings at least.

For the general case, it might be worth doing something like you mentioned, but making the added integer member optional. One way to do this is to consider cases like this as union cases:

struct links {
union {
struct href deploymentBase;
struct href cancelAction;
struct href configData;
u32 fields;

The `fields` member would have 1<<0 set if deploymentBase was decoded, 1<<1 if cancelAction was decoded, and 1<<2 if configData was decoded. The href struct wouldn't need a `fields` member of its own since it's not a union case.

Now, using a union wouldn't work if deploymentBase and cancelAction could be set at the same time. In this case, one just removes the union declaration, and things should work. The only confusing bit is that this would still be a union case, but without the declaration of a union properly.


Join to automatically receive all group messages.