Null values
On our RadarOn our Radar

Full widespread support for null values, in all layers: database, actions, ...

Not fake zeros disguised as nulls, but real thing, the ones that we can compare to is null. The ones that mean "I don't know the value for this... I don't even know if its zero"

Nuno Leong
this is a no-brainer ... null values exist, a lot of business logic depends on them, they can't be ignored or faked.

The platform would definitively increase it's value for the customers and developers if the real nulls would be there.
2016-04-21 20-09-54

well, I hate null-values in my applications and would like to prevent them wherever I can.
It's such a typical database thing and with Outsystems in principal you don't need to know how data is stored.

I don't have the option to prevent nulls... My applications tipycal integrate with other systems which use and require nulls.
Without nulls you cannot tell wether there is a value for the field or not; you always endup with a pair of attributes for eache piece of data: one with the value and another with a boolean to determine wether the values is really a value or if it is the inability of the platform to represent the absence of the value.

And most other systems that you connect to will support nulls and may require you to use them: databases, DLLs, ...

It isn't about how data is stored, it is about the quality of your data.
Adding null value support would not remove the option of avioding nulls from those who would like to do so.  It would, however, help with migration of legacy applications and databases to the Agile Platform, and would therefore be highly useful.
Definitively i agree on having null values on the platform.

Since i work with outsystems and oracle (ebusiness suite) i've been having lots of problems with null to text and text to null conversions consuming a lot of time sometines analizing complex queries just to find again the same conculsion: "Ups! it''s the null to text problem again!" ...
We have just started developing with Outsystems Platform and having problems on dealing with null values. Our existing database (as everyone´s else, I supose) does have a lot of columns with null values, as part of the business, and it has been very anoying to deal with it in Service Studio. NULL values in Service Studio would be very welcome !
When using a DateTime dataype in a web service, and the value is null a date and time is returned.  1900-01-01T00:00:00.0000000+11:00. 

To remove this date we had to change the datatype into a string, which isn't very nice at all.

It doesn't matter too much that null is 1900 within outsystems platform and applications but its important to have a true null value at least for 3rd party using our pubic web service.

best solution for date-time values is a timestamp; 0 is known by any unix system
The way that the platform handles nulls it's, in my opinion, one of its biggests drawbacks. 
Having a 0 or a null are two completly diferent things! One thing is a student without a note, another thing is a student with a note of 0! Now they are handled the same way.

So, 1000 likes to this idea...
The everlasting story of NULL-value. NULL is the value used to represent an unknown piece of data. Null is not equal to zero.  Good idea!
I want to be able to use simple query and check the condition that database date time field is is like writing like this : TABLE.DATECOLUMN IS NULL..but I am not able to acheive this using simple query
The date issue mentioned here is a particular problem for an application I'm working on.  I have birth dates that range from the late 1800's until now.  With the inability to represent any of these old dates and to treat everyone born on 1/1/1900 as NULL I too have to convert to strings.  We really need support for a true NULL and for timestamp data type to handle wider date ranges.
Not having Null values is a real problem.
OutSystems supports no NULLs...!!! And no dates before 01-01-1900...!!!

I can not imagine that everyone uses 0 for NULL in integer???? And 01-01-1900 for NULL in date???

What if 0 is a perfect valid value, and NULL too, for integer?
What if 01-01-1900 is a valid date? What if you have to save the construction date of a building of 200 years old? What if you want to store genealogy?
Since when do we build systems that deny any history older than a century???? For me this is really unbelievable!!!

And aside of the functional aspect, storing 0 or 01-01-1900 instead of NULL in our database would explode the size of indexes - I can not tell my manager that our database will grow from 4TB to 7TB, just because a tool does not support this !!!
Why in the world does someone behind a desk designate perfectly normal live values (0 or 01-01-1900) to fake values?

It is not just a "real problem"... That's the kind of things we sove daily.
It is much worse. It makes the product unusable for a great deal of data driven applications, and in many cases unusable for real life representation of data.

What I mean: there is quite a difference between not having money in my purse ( = 0 ) and not knowing how much money I have in my purse.
There is quite a difference between a building of which I don't know the construction datet, and a building of which the construction date is 01-01-1900.

And why did OutSystems dictate that I can not save the fact that Abraham Lincoln was president till 15 April 1865? Or that Portugal invaded Spain in 1702?

This severely limits usage of OutSystems for any serious data centric systems!!
Till yesterday we considered OutSystems seriously for our enterprise system.
Since I know this, we have to revisit this decision. We are still evaluting the next few months, but little chance that we choose OutSystems if it does not support NULL or dates before 01-01-1900.
Hi Jan,

The calendar widget will only let you select dates between 1900 and 3000 but you can type the date directly in the input field (instead of selecting from the calendar) and OutSystems platform will accept (save/read) dates between 1753 and 9999.

The discussion of having nulls or not is a different one.
After I cooled down a bit (I was really shocked that OutSystems does not support NULLs)...

Besides being really awkward for developers and admins, I came to the following list of major enterprise problems caused by this problem.
  1. Big risks for bugs & runtime errors when reading data from (existing) databases, XML, webservices if NULL or absent is interpreted as 0 or 01-01-1990 (reading NULLs, interpreting as a non-NULL)
  2. Same for the other way around, if 0 or 01-01-1990 is interpreted as NULL (reading non-NULL, interpreting as NULL)
  3. Industry-standard behaviour of external tools (e.g. reporting, like Jasper or Crystal) etc. is deceived.
    * ORDER BY, GROUP BY, IS NULL will not work as expected anymore.
     * NULL does not influence COUNT(value) or AVG(value) (average); but 0 and 01-01-1990 do influence these.
    Reports that worked perfectly will start to produce errors, because OutSystems fucks up the data.
  4. Because of OutSystem's non industry standard behaviour, a database written to by OutSystems will become incompatible (forever!!) with any other platform / application. It becomes impossible to have an other applciation work with the same database as OutSystems. An maddening technical vendor lock-in, and a major impact on your application landscape.
  5. Lots of wasted extra storage. For MySql and MS SQL Server the required additional storage typically will be something between up to +25% storage needed. For Oracle this will quickly be something like +40%; Oracle does not store NULLs in indexes and optimizes (eliminates) storage of NULLs, hence the additional storage when NULL is stored as a non-NULL value.
  6. OutSystems forces users to awkward :-(( workarounds.
    Examples I found on OutSystems fora:
  • Store dates in textual format instead of natively (losing all handy features of date validation and arithmetic)
  • With every numeric or date column in a database table, include an additional column indicating whether it is actually NULL or not
  • Database triggers transforming 01-01-1900 to NULL in the database
  • Updateable views that transform NULLs to 0 / 01-01-1990 (to please OutSystems) on reading, and transform 0 or 01-01-1990 to NULL on writing (to please OutSystems while at the same time keeping the database compatible with industry standard behaviour)
Like it or not, NULLs are omnipotent in databases, XML, development tools, programming languages, platforms, heads of developers.... Everywhere around you!
Hi Jan-Hendrik,

Have you considered the "Default Value behavior" setting, described in the Integration Studio online help ( ?

This parameter allows you to map NULLs in external databases to unusual values such as 1st Jan of 2893 and seems to solve the problem of storage taken by indexes in external databases.

Let me know if this helps, or if you face any difficulty implementing this suggestion.

There are indeed very good arguments for and against the use of NULLs. You can easily find several discussions and even research papers, with passionate and strong arguments on either side.
As an example, this help section ( about "designing for missing information" seems to provide a reasonably balanced view of the issue.

OutSystems decided not to have nulls in the language quite some time ago, as a way to make it simple to develop on OutSystems and avoid creeping errors on business logic, which tend to be expensive to handle.
We understand from day one that this approach also has downsides, especially on the integration with other data sources. Nevertheless, we still believe that the benefits outweigh the disadvantages.

Thank for sharing your feedback.

Hi Joao Santos, it sure would be nice if Outsystems at least gave the option to the developer. This would seem to solve the debate of being for or against using NULLS. If there are senerios like Jan-Hendrik van Heusden described then one would have the "option" of choosing to use real NULL values rather than fake ones. It would be nice if this option was built right into the platform so as to make it nice and easy on the developer to set an option like "Use REAL NULL values" on attributes where REAL NULL values are imperative. To me debating whether or not using NULL is good or bad is one thing, but removing the option from the developer is a completely different thing. Just my thoughts on the matter, thanks!
Null values are a must have.
They are not just some 'database-thing' like some people claim here, they originate in programming languages and are the value of a variable before it is assigned any value.

2016-04-21 20-09-54
Thinking about it some more and more and I'm finally getting into the agreement mode.
Why, because the solution Outsystems implemented is a bad implementation in the first place.

what is good:
for PK/FK is 0 a perfect alternative to null, at the moment I don't see any major flaws there.

what is bad:
0 and 1/1/1900 as a null-equivalent  for "normal" integers, dates.
and strings also ofcourse.

why is it bad?
how can you tell if a user entered 0 as a value or skipped the value?
(for example a discount value)
how can you tell if a user entered 1/1/900 as a date or skipped the input.
(birthday comes to mind)

The reason because it makes developers easier is not a very handsome one.
we already check if something is a NullIdentifier() or a NullDate(), we already program in that way.
And we introduce complex logic because we want to know if a user entered nothing or something.
and we need to figure something out how to store that in some way.
so even if the "proper" nulls are implemented, nothing changes much.

there is an inconsistency with the REST webservices.
We can send default-values or not, and that imho is already some sort of controlling the nulls in a proper way.

Dear OutSystems,

I would like to challenge you about this topic. Can R&D write questions / challenges you have about how to handle null-values, so the community can respond and perhaps R&D and the community comes up with 'the' solution?


For a platform that states to be good for integration between systems, it really have to support null dates as: 
<Value xsi:nil="true" />
Hi all,

 just wanted to bring some new thoughts into this discussion. I also miss NULL values in OutSystems, i.e. the possiblity to state or check that a given variable has no value. Nevertheless, I'm not in favour of introducing NULL values. Instead, I'd rather have something similar to the  Optional type  in Java (see:

 The Optional type is a wrapper for an instance of another type. Basically, it encapsulates an instance that may be absent. You can create an empty Optional (that contains no instance) or an Optional containing a given instance. Once with the Optional in hand you can ask it whether or not it is empty, to return the instance in it, to return either the instance in it or a given alternative value if empty, etc. Many more methods are available.
 The "beauty" of the Optional data type is not that it allows us to express that a given value might be absent, but that it makes the code that deals with potentially absent values easy to read and to write. In addition, it prevents the famous NullPointerExceptions.
 Check out the following link on Null vs Optional:

 What do you guys think?

2018-05-06 02-00-13
João Melo
I think it's a MUST HAVE

I also think it's a MUST HAVE; see the examples of J. on 10 Jul 2015.
The use of Null shouldn't be a discussion (

And if there is a discussion, this should be on the technical implementation of Null values.
Null is not implemented a value. Null is implemented as a seperate status(-byte) in front of the field, a Null-indicator. All actions on Null values use this Null-indicator.

This construction can als be used by Outsystems. The code_generator of Outsystems can generate a separate indicator(-byte) for fields that can be NULL.

The Null-functions (e.g. NullIdentifier(), NullDate()) must use the indicator part and should ignore the value of the field.

Another Null challenge is sorting.
The SQL standard does not explicitly define a default sort order for Nulls. Instead, on conforming systems, Nulls can be sorted before or after all data values by using the NULLS FIRST or NULLS LAST clauses of the ORDER BY list, respectively. Not all DBMS vendors implement this functionality, however. Vendors who do not implement this functionality may specify different treatments for Null sorting in the DBMS.

The nice one is Null on Boolean. In my opinion, a Boolean can't be Null. A Boolean can only be True or False.

I will give some examples.
In this examples the first character is the Null-indicator(byte), where 'Y' means = Null (True) and 'N' means <> Null (False).
Date1 = "Y2016-10-02"
Date2 = "N2016-10-02"
Date3 = "Y1900-01-01"
Date4 = "N1900-01-01"

IF Date1 = NullDate => True   ("Y" = "Y")
IF Date2 = NullDate => False  ("N" = "Y")
IF Date1 = Date2     => False  ("Y2016-10-02" = "N2016-10-02")
IF Date3 = NullDate => True    ("Y" = "Y")
IF Date4 = NullDate => False   ("N" = "Y")
IF Date3 = Date4    => False    ("Y1900-01-01" = "N1900-01-01")

IF Date1 > Date2    => True    ("Y2016-10-02" > "N2016-10-02")

Example with text:
Text1 = "YJohn Doe"
Text2 = "NJohn Doe"
If Text1     = Text2    => False         ("YJohn Doe" = "NJohn Doe")
IF Text1 Like Text2  => False          ("YJohn Doe" Like "NJohn Doe")
IF Text1 > Text2      => ??? (True)  ("YJohn Doe" > "NJohn Doe")

==> Technically the indicator can be a boolean.

Another reason why nulls should be supported is the following:

At this moment it is impossible to create a unique index on a nullable column. This creates a huge problem since it is quite a hastle to enforce uniqueness in a different way without creating a lot of negative side effects.

In my view: when you allow Outsystems to build applications on top of a specific data base brand you must support at least this level of constraint control. In the end it's the data that RULES !!!

it seems as a nice trick to use 0 as null, 1-1-1900 as nulldate and " " as NullText.
But, 0 is a number, 1-1-1900 is a datavalue and " " is a text-value.
it would be exactly the same as: 

we will not use the number 9, character b and date '01-11-2011' (because that's our value to represent a null).

I totally agree with João (and the others that plead for the addition of null values)!

Please for the love of all that is good and kind NO! Null values account for half of all errors. While the method that OS uses to deal with them atm is pretty terrible itself, we should rather implement the Maybe pattern or a empty collections as they occur in Functional Programming languages.

Let's not encourage the awesome sause that is OS to patch instead of to radically rethink!

2020-12-08 09-54-08
Evert van der Zalm

Keep missing them more and more....

Yes, I would realy like to have real NULL values.

I just want to share the idea how to deal with Null value.

This may not be the best way but I think it would help someone who have a trouble dealing with it.

The way to deal with Null value is to set the lenght of DB data larger/lower than the lenght of user input.

Which mean that developer needs to re-config DB to make sure that there is a space for Null.

Surely developer also need to set Null value on every Input to implement this method and also filther the display.

It's going to be a long development.

Without using Null, at least I want to set my own Null value for the environment or e-space level to make sure that Null and 0 is not equal.

And if the decided Null value can be automatically be hidden, it will reduce time on development a lot. 

NULL values is a necessity, especially for BI purposes.

So how do you consume this REST response (with a null value) in Outsystems?

"deposit": null,
"deviceId": ""

I understand the problem and the justifications for not including nulls (or unset optional values, or whatever you want to call them), but in our situation where mathematical group aggregations are at the core of what we deliver (GROUP BY + AVG/MIN/MAX/SUM/COUNT) it may be untenable. Which is too bad considering that everything else about the system seems a great fit. 

Background: I have the same issue as found at and have thoroughly read through both viewpoints in this post as well.

But we have a major difference – the size of our data. So here is a real example:

  • We have tables full of data metrics (decimal fields), and queries with as many as 16-20 columns sometimes by the time it’s all joined up. This means whatever “solution” is used to work around the should be done during the SQL query if we don’t want to do 16-20 separate queries for what should be just 1 query
  • The unaggregated results occupy hundreds of thousands (even millions) of rows
  • After GROUP BY the aggregated end results would only occupy about 100-200 rows to be shown on the front-end
  • It is *required* that some of those fields do not have values and are thus excluded from mathematical aggregates (AVG, COUNT, etc.). Imagine the difference between averaging [0, 0, 10, 10] and [null, null, 10, 10] – without nulls they get a 5 instead of a perfect 10!
  • There is no way to factor a separate “isSet” Boolean field into the SQL aggregates during the query that I’m aware of, it would have to be done in application code afterword (which would be an absolute nightmare to maintain)
  • Performing the aggregates in application code would be horribly inefficient! You would be returning a list up to 1,000,000 items long to the application server, just so you can iteratively run additional logic on *each item* and then finally work it down to an additional 100-200 rows of data you actually needed, all while the RDBMS already has this capability. Imagine multiplying this inefficiency times the number of active connections querying data and you’ve got an application server weighed down by 10,000 times the RAM usage per request.
  • Exports can no longer be done directly from the database as they will contain the “filler” default values.
  • Streaming database results (for sets too large for an all-at-once API request) for other integrated systems (think BI) are not possible unless we also program them to handle the “default” or “separate isSet field” values as well, and then somehow keep them all in sync as the systems evolve over time. This would be a very complex, time-consuming, and unreliable effort that would have to be perpetually exercised and would continually worsen.
  • Pre-calculating and caching are not viable options since our data is often realtime, and even then the caching mechanism would still have to face the same maintainability challenges

 So in short, it’s not that I’m advocating for nulls specifically – but I need some feasible solution that allows non-applicable numerical values to be excluded from mathematical aggregates while still at the database query level, and at the same time not require error-prone, messy, hard-to-maintain applicaton-level workarounds that put the burden back on the developer (which is what Outsystems is supposed to facilitate).

I agree, though I imagine that would be a major breaking change for the platform.

My legacy project with Oracle Form has a table with a paymentdate field- null if a customer hasn't paid his contract or not null if he has-. Then we extend the project using Outsystems. When we migrate data from the Outsystems to the legacy one, we must take more effort by checking if the paymenetdate is a dummy date. In the worst case, a customer will be considered has paid his contract..:(..what a pity! - What a dangerous thing not to have a NULL - which means there's no information - in Outsystem data abstraction.



It is important to have null values!

I am in agreement that supporting null values should be included in Outsystems. I could list my specific examples of how it would help me, but I feel like there is more than enough explanation from the previous posters to convince anyone that this is a good idea.

I agree it's really important to have NULL values!

I don't know if it would be feasible or not but maybe there could be an option to enable NULL values in your app (which would be off by default for people who don't want to deal with it).

I agree that its really important to have the ability to know if a value is not set.  I do not think that you have support NULL per se, but there should be the ability to know if a value has been set or not.

I do not like how systems like Oracle treat NULL and "" as the same value.  They are not.

I like the Optional idea, where in .NET you have the Nullable<> type.  This allows for a cleaner way to see if you have a value verses not having a value.  Which there are many valid business reasons to have this check.

Changed the category to

First real downside I'm encountering while working with outsystems is the lack of NULL (for dates/integers specifically). 0 and 01/01/1900 are often a valid values, and adding a boolean to indicate whether another attribute is empty or not just works very unintuitively.

+ integrating with other systems is just sooo much harder now

Almost 8 years later :( Still no update on this!

It's clearly something missing in OutSystems to make it better and easier to use with databases.

This is a MAJOR problem that needs to be taken care off. 

Non mandatory numeric/decimal values are set to 0 when not filled! Makes no sense to me. What if the 0 value is not acceptable, I have a project where this happens, the field is non-mandatory, but if filled, must be greater than 0, now what?

2018-05-06 02-00-13
João Melo

Hi Daniel, I totally agree with you and the other guys who posted here. I think it should be addressed as a critical issue.

But in the meanwhile there are some quick solutions. There is a property called "Null Value" on any text field. Have you tried to set it to "0" and see if it works on your project?

Hi João, thanks for the idea, but in my case it won't work, I need the opposite. 

I have some decimal fields in my entity that are non-mandatory, but if filled must be greater than zero. This means that if I leave the inputs blank, the platform will set it to 0, an incorrect value in my bussiness logic.

I'm considering having all my numerical/decimal values set to Text to overcome this limitation, but that is just a nightmare in all fronts... no easy wins here...

Hi Daniel,

Did you evaluate the option to set "Default Value Behavior" to "Convert to/from Null value in Database" (

Or choosing a default value other than 0 for your attribute?

I didn't understand the full details of your problem... is the "0 as an incorrect value in your business logic" being processed by an external app, OutSystems app or both?


What can be done and we are actually doing waiting the null value is to define a default value that can't be accepted in central database and add triggers in database to change that value to null.

Hi Fabien,

How is that better than using the setting  "Convert to/from Null value in Database" ?


It will allow us for some attributes of entities to manage difference between null and 0 (that can be a correct value). For ex having a negative value as default value for an attribute that can't receive a negative value will tell us when triggering  insert/update that it should be null and it will let us enter 0 in that attribute.

Hmm... but the "Convert to/from Null Value" works together with the Default value for each attribute. You can have a negative value as a default for an attribute.

E.g. if you set in Integration Studio a default value of -2 for an attribute, assign a value of -2 to a record in runtime, and set "Convert to/from Null value in Database", OutSystems will store NULL in that attribute for the external table.

Using these two settings in Integration Studio seems simpler than creating a trigger in the central database?

And much cleaner, since you don't need to "pollute" the central database with a logic that is useful only for the integration with OutSystems.

Hi Joao,

I will give it a try, that was something I misunderstood then.


2017-07-05 12-29-35
Carlos Alfaro
Merged this idea with 'Is is possible to support null in Outsystems' (created on 13 Nov 2018 11:31:20 by Shashi kant Shukla)

Suppose there are having a entity named Employee, data type of a attribute(Salary) of entity in decimal then below are cases:

Case 1: User not entered any amount from screen for Salary then 0(default) value will store in database.

Case 2: User entered amount 0 from screen for salary then 0 stored in database.

So in this case unable to identify if 0 is stored in database is default value or user entered 0 so my suggestion is default should be null in this case we can clearly identify user entered value or not.

This comment was:
- originally posted on idea 'Is is possible to support null in Outsystems' (created on 13 Nov 2018 by Shashi kant Shukla)
- merged to idea 'Null values' on 13 Nov 2018 11:37:03 by Carlos Alfaro

I was blown away when I realized the glaring flaw in outsystems.  The idea that any system presented itself as a major development tool and lacks nulls was unbelievable.

Yes, there are some workarounds, like dummy values or storing numbers a s strings, but that's just not an acceptable answer.

There is an absolute need to distinguish between numeric values that are 0 and ones that we don't have data for.

How ridiculous is it that if I store a persons birth and death date, I can't store a null to say they aren't dead.

2018-11-08 13-17-53
Kilian Croese

I second the idea of having a solution to work with NULL values. I don’t have any extra use cases than the ones already described before.

The work-around they suggest of storing decimals as text is not even valid as the TextToDecimal() function converts Null text entry into zero! This contradicts their so-called philosophy of having strict typing of fields because it errorneously lumps Null with Zero.

Unless one can be absolutely sure that in both the past and future instances of an attribute, the Null entry will not arise (I can't see how that can be the case unless one is happy to use Zero as a default entry), then one should always stow numbers as text. Which means that they should not even provide decimals as an attribute type at all!

Also for those who are happy to use a default zero in lieu of Nulls, some thought should be given to the calculation of averages, percentiles, median and other statistics because the substitution of Null values wiith zeroes could skew those statistics severely.

The insistence of rejecting Null entries forces inefficient work-arounds and additional filters. 

This was just a mistaken choice and the sooner Outsystems changes it the better. 

Please, I will not duplicate the never-ending arguments do support this and make things the right way as many already did.

Don't lost the chance to do this at next major version.

Discuss it with very high executives to share the impact and business strategy to support the big change.

But don't be intimidate by this and fix this wrong concept you have bad thought in past.

If you want to say that OS is great/big fix this kind of mistakes. Even with a big impact. Don't let people be hostage by this misconcept and let this to other integrated systems spreading this to rest of the world.

The non availability of NULL values adds time and complexity to our work; it adds costs to an already expensive OS platform, and redundantly slows the rate of production.

Just a little bit the opposite of the offer?

In my 35 years of doing database development with Oracle, Sybase, and SqlServer, the use of NULL is critical when doing aggregations and indicating incomplete/missing data. After reading the responses from Outsystems I am more than a little more than surprised that it believes that the large database vendors have it wrong. Outsystems does not state that directly, but indirectly by stating that not supporting NULL's is a feature and not a bug. A true feature would not require the proposed workarounds. 

If the issue is that Outsystems has architectural limitations that prevent it from supporting NULL's then please state that. I have been a developer long enough to know what it means when someone says, "that's a feature, not a bug."

Completelly agree with Geraldo. It souds like a big mistake years ago and now it need to be treated like a "feature".  Who want to pay for a great breaking change to fix a mistake like this.

Completely agree with Geraldo and Márcio and all of the others who know the difference between nothing and something on this.

I've been a developer since 1981, when still in childhood. NULL values are essential. There is a difference in the real world between the absence of a thing and a thing and in the real world you cannot get away with substituting the absence of a thing with a surrogate thing.

I strongly doubt Outsystems will ever migrate away from its 'decision' not to use NULL (and I'd hazard a guess this was born more out of a null pointer fear than from adding value to the platform). It is clear from even the smallest amount of c# extension writing that they use long (the primitive) instead of Long (the object) etc. and to convert would require an almost complete core rebuild.

My experience with the platform has been that the 0 = NULL conundrum has been more of a nightmare than having a real null would be (and believe me, I'm used to them - and I still get the odd null pointer that 9/10 times tells me I'm doing something wrong in my logic).  How often do I have to check if my value is a pseudo null instead of if it is a real null? Always. That's how often, only that I cannot tell the difference between the absence of a value and the value of zero.

Had I known about this use of surrogate nulls thing before my employer invested into using the platform I would have advised that it was a deal breaker and to stay well away from it. I would now advise anyone else to do just that.

Yet another reason that NULLs are necessary - NULLs, when implemented, always return false when being compared. For example, NULL == NULL should return false. However, Outsystems would return true, since NULLs are given a value.

This means that if you need to join two tables on a nullable column, you need to add in awkward logic to ensure that all of the psuedo-NULL values in one column don't match with the pseudo-NULLs in another column.

When people argue for not implementing NULLs, they usually mean data columns should not have the capability to hold NULLs - any column that needs to be nullable should be normalized into a new table, with rows only if there is a value. In this case the absence of a row indicates a NULL. What it does not mean is replacing NULL with a sentinel value. 

Solving the problem of NULLs by giving them a surrogate value is like reducing crime rates by repealing the laws that get broken - the problem is still there, it just doesn't get reported. The end result is that developers need to implement proper NULL functionality, usually in an unclean, inefficient, potentially buggy manner.

I completely support this idea.  Not supporting null values gives too much headaches. And I can't put my head around the fact that, the way it is now, Outsystems is returning unexpected results. When I query the database for a record with a null value in it, I expect to get the null value, not an ilogical 0 or "" or 01-01-1900. This conversion brings much more problems than null values existence, as Jesse Li and Tom Rowland so well stated.

0 +

2016-04-21 20-09-54
Merged this idea with 'Null Value for different data type in OutSystems , Especially Date one .' (created on 08 Jun 2020 06:07:36 by pranav pandey)

Hi All,

I have been facing issues with the null values that outsystems have for the different data types, especially with the date one. The null date in OutSystems is 1900-01-01. This causes issues while integrating with other systems.

Example: I have exposed some rest API which is been consumed by my client (a government agency). To handle the null date that we return, they have to write a  wrapper logic to map it to them, which they didn't like it.

We need to come up with some way to handle this and make it consistent with all the other systems. 

This comment was:
- originally posted on idea 'Null Value for different data type in OutSystems , Especially Date one .' (created on 08 Jun 2020 by pranav pandey)
- merged to idea 'Null values' on 08 Jun 2020 07:18:31 by J.

My latest one is from where an aggregate filter sees BIT=0 as NULL because Outsystems will put NULL into my database instead of 0, and so field = false or field <> true returns false when NULL. I now have to remember to use (field = true) = false to work around the issue. I cannot turn off the convert NULL values option for this table because other fields require it.