Hi Martin,

Is there any value that is invalid?... you can use the Null Value attribute of an input to specify what should the empty input value be.  

You can use the TypedValue runtime property of the input and check whether it's empty.

There are no invalid values. And I forgot to tell you, but it is a mobile application. The Typed Value Praperty isn't implemented there.

Ok, so there's always the possibility to bind the input to a Text variable. In that case, you will need to perform validation yourself.

Another possibility is to fetch the input value in a Javascript block. Create a Javascript block with InputWidgetId as input, and TypedValue as output. Then write something like:

$parameters.TypedValue = document.getElementById($parameters.InputWidgetId).value;

Martin Rozeboom wrote:

Hi Martin,

did you find a satisfactory solution for your problem? I also am disapointed that I cannot store empty values. There is no way to tell whether someone deliberately stored 0 or didn't input anything yet.

My understanding of another workaround is to store the decimal as text which accepts an empty cell represented by "". Then use the TextToDecimal() function to convert to a number if calculations are required. I have the same problem that a default to zero has very different implications from an empty cell - particularly since I use the data in a machine learning programme so zero and no data have different connotations. I have not tried the TextToDecimal function yet but I wonder if it converts a null text cell to zero. In which case I end up at the same problem with not being to tell the difference between zero and true null?

Hi Tommy, yes TextToDecimal function would convert an empty string to decimal 0. However, you could check if you got an empty string with the If function, or you could use TextToDecimalValidate which would return false for an empty string.

For those still coming to this thread, there are multiple workarounds described above, and summarized below. If you feel that none of these workardounds are valid for your scenario, then please state your scenario clearly so we can help you. If you find a workaround that solves your problem, then I see no point in continuing posting to this thread.

The lack of distinction between nulls and 0 is a feature in OutSystems, not a bug. If you want to influence this decision, feel free to like this idea: https://www.outsystems.com/ideas/213/null-values

Workaround 1: use a text variable, then use TextToDecimalValidate/TextToDecimal to safely convert the value into a decimal before using in business logic.

Workaround 2: use TypedValue runtime property of the input widget, which is available in web applications.

Workaround 3: in a mobile application, use "document.getElementById($parameters.InputWidgetId).value" inside a JavaScript node to retrieve the typed value as text.

Although I understand Outsystem's intentions for having the strong typing of attributes, this treatment of decimals and Null is a serious flaw for several reasons:

1. Unless you have complete confidence that you will not have a Null entry in a decimal attribute, you will have to store everthing as text, and have to convert back to decimal for math operations. In my case several hundred attributes have to be stored as text. I cannot think of any situation in which one can have complete confidence that Null will not appear in an attribute - even precise scientific experiments may encounter instrument failure in a small number of situations. So the only way in the real world to maintain the integrity of the data is to enter it as text rather than as decimals. So you might as well not have the decimal attribute type at all! You can only comply with its strict rule if you are prepared to brush the nulls under the carpet and arbitrarily insert zeroes in as in any measurement situation there will always be the chance of having nulls in the future.

2. The only reason I would store decimals as text is to preserve this distinction between Null and Zero (hugely important difference in meaning in my context of finance). However, in converting back to decimal for operations, the default to convert Null to zero lands me back to my original problem that Outsystems does not understand the basic logic that Null and zero means very different things. So I would have to add an additional filter to exclude these rows when a math operation is used. So if you are going to force me to add this filter for each operation, then you might as well accept Null as a decimal and let me filter decimals directly rather than the inefficiently need to store as text then reconvert to decimal then to filter for Null!

3. The treatment of Null as zero skews aggregate calculations like Average, Standard Deviation, Percentile and Median as Null should be automatically excluded from such calculations while genuine zeroes should be included.

Just to clarify some things on this thread.

1. OutSystems definitely support NULLs on the database. See attached example. The key for that is to use SQL queries, both for storing the value and for retrieving it. However, when those values are materialized in memory, the NULLs are converted into the default value. You can use that to your advantage, if the semantis of the NULL align with the default value. Or you can learn how to extract this information into a boolean, and use the boolean to build your own semantics for a NULL value.
2. Nowhere in this thread we have recommended (or even mentioned) storing a decimal value on the database as a text field. My suggestion (which I called workaround 1) was to use a text variable - and that was only necessary because in Mobile there is no TypedValue property to read the text typed into a field. I did not mean to store the value as a text. This was only necessary to distinguish an empty "" field from a filled "0" field, and then act accordingly. My two other alternatives (workaround 2 and 3) do not require using a text variable, although one is only applicable for web applications, and the other is only applicable for mobile applications.
3. Even if OutSystems were to introduce the use of NULLs in builtin types, application developers would still need to build business logic to handle each NULL value. This is usually accomplished with defaulting to some value in case a NULL is found. In those cases, that's precisely what OutSystems is already doing, saving you the trouble to null-check!
4. Other scenarios might require more complex handling of NULL values, and I believe most people reading this thread is facing such a scenario. Usually NULLs are handled by having an If statement with a null-check, and then executing some logic if the value is NULL. In this case, having a builtin NULL value or having a boolean flag to explicitly describe the semantics that the value is unknown would not make any difference. Both can easily be mapped into the If statement. In my opinion, the second is more explicit.
5. As I demonstrate in my attached example, you can derive the null-ness of a value from the database without requiring a separate boolean field on the database, as long as you stick with SQL queries. You can build your business logic using that derived boolean, the same way you would build your logic using If (null-check) statements.

And, perhaps mandatory for anyone reading this thread, please listen to Tony Hoare's (who proposed NULL back in 1965 as a builtin value of every type): https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/