Visualization of Null vs. Empty String Inputs

[jmlowden]

This issue rears its ugly head from time to time - app behaves unexpectedly (especially with inputs used to filter table results) due to the difference in handling between null vs. emptystring variable inputs.

This post got me thinking about it again:

Problem: One table filter doesn't work

I don’t have the “clear X” feature yet but I would call that a bug too. We added small “X” buttons for each filter field on our UI to restore the value to null so that we can get results when the filter is null.

And I got the “Your topic is similar to…” notice about these older posts of mine:

Better handling of NULL vs an empty string

We are running here into an issue where we need to differentiate between a logical NULL value of a field and an empty string. Let me give you an example: Let’s assume I have a table where is have two fields on which I want to filter, A and B. Usually, there will be a value to search for in both fields. However, there could also be cases where one of those fields is actually NULL. In such a situation there seems to be a issue where if I query now with one of those fields empty, I am not getti…

Empty String vs. Null Remediation

In trying to follow the best practices for creating sequential record IDs, I ran into an issue wherein I was getting different results depending on whether the intermediate variable containing the “starting value” was blank, in either the blank=null or blank=empty string fashion. For example, in populating the starting value by popping a value from a specific array index generated from the previous record ID, if the record ID was missing the numerical suffix, it would generate an empty string, …

I would propose that there be some consistent, readily discernable visual difference between input fields that are null vs. emptystring - perhaps the null symbol ∅?

Also beneficial would be a consistent effect across inputs of “clearing” the input - to me this default behavior should always be actually clearing (setting to null) the variable vs. just emptying the string, and if special case behavior is needed it could be contrived through trigger logic (e.g. restoring to a default value).

[thorsten.langner]

@jmlowden

Also beneficial would be a consistent effect across inputs of “clearing” the input - to me this default behavior should always be actually clearing (setting to null) the variable vs. just emptying the string, and if special case behavior is needed it could be contrived through trigger logic (e.g. restoring to a default value).

I agree with that … you can actually empty a string in an input widget, with del- key or backspace.
But there is no way to clear it. As soon as an operator typed something, there is no way back to the initial null value. (Only if i built another button for that. Which is not very intuitive for an operator…)