Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should nulls be handled? #39

Open
jwise-mfg opened this issue Feb 25, 2025 · 4 comments
Open

How should nulls be handled? #39

jwise-mfg opened this issue Feb 25, 2025 · 4 comments

Comments

@jwise-mfg
Copy link
Member

Discussion points so far:

@aronsemle
Copy link

Are there cases where I'd do anything useful with a null?

Here is an example of removing them. I want to store some part of the namespace to SQL. Assume the table doesn't exist yet. I read an ElementID on the API to get the values out, and on the first read try and create the SQL table with the data. I have nulls in the data. What do I do? I can't create a column of type null. So I need to leave them out anyway, and update the table later if/when that attribute has a value.

I personally I'm not a fan of null, NaN, etc, but I lose this battle with my dev team all the time. The hard part is null doesn't have a data type and not all destination systems support.

@randy-armstrong
Copy link

randy-armstrong commented Feb 26, 2025

The OPC UA rules:

Types are nullable or non-nullable.
Non-nullable types have a 'default value'.
Alternate representations of a "no value" are considered semantically equivalent (null and "" or null and []).
Metadata can be used to specify that a field in a structure can be "not specified" and what happens if not specified (i.e. nulls are allowed within a specific context - not as a general rule).

@graemewelton
Copy link

To your original points @jwise-mfg:

  • Null is an error condition (e.g. communication failure, divided-by-zero, etc.). It is a valid indicator that there is no value, which is equally important to non-null data.
  • Not necessarily, bad quality data can be non-null. In systems where Quality is not a concept, null values are a robust way to indicate an error condition.
  • I am not concerned whether we call it null or undefined, but we do need at least one of these "bottom types" to indicate "no value". My preference is null.

Regarding type, I believe all our types should be nullable.

@randy-armstrong
Copy link

There are 2 contexts where null shows up:

  1. The primary value
  2. Fields in a structured value.

In OPC UA 1) is always nullable. The additional rules apply only to fields in structures.

Null is not necessarily

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants