"null" values not supported

[rockethacker]

When unflattening from json string, and a json pair has a null value: {"string":null} it is deserialized into a "LV Variant" data type regardless of the LV data type you pass into the function. this causes an error when you then try to covert using the "Variant to data" primitive. This issue exists for all data types. I would expect that the default value would be returned.

Here is an example of this in LV

This issue is discussed in length here http://stackoverflow.com/questions/21120999/representing-null-in-json

I would recommend fixing this issue as follows (this would nullify my proposed fix for #12):

I believe that addressing this will also address #7 and #12.

Note that i'm actively seeing this issue while writing a LV jira api wrapper.

[robertbcalhoun]

There isn't a single best way to handle nulls in LabView. If the library automatically converts to the default data for that type, then the calling function cannot distinguish between e.g. {"a":""} and {"a":null}. In many of cases (especially with databases), that is an important distinction.

The built-in LabView JSON parser lets the caller choose between returning the default value and throwing an error. It's probably wise to follow the same model as the NI function and let the caller decide how to handle it.

[rockethacker]

Understood there are special considerations when working with databases.

My main issue is that the unflatten function takes in a user-specified data type and outputs a variant version that doesn't match that data type. I'm not too concerned with the database case because it doesn't work in the more general use case.

[tmaila]

Fixed in build 1.0.5. by defaulting to deserialize null values to default values. Optionally null values can be deserialized into empty variant / empty array / not a path values.

[tmaila]

The implementation was changed in release 1.1. The current implementation deserializes all null values to values that best match null values for each data type. Naturally LabVIEW types don't have null values so this is somewhat of a compromise. But guarantees that the output is always of the right type instead of throwing an error. There is an option Nulls as Defaults which when true returns user specified default values instead.

To be able to distinguish between null values and non-null values one has to deserialize the value into a variant. For example if you have a JSON object where one of the elements is a string and that string can get null values, then create a LabVIEW cluster where you replace the string with a variant. There is a VI Is Null that can be then used to check if the value is null. If it is not null, then either Adapt to Type or Variant to Data can be called to get the value as the type you intended.

[robertbcalhoun]

This seems like a good approach.