Hacker News Reader

Comment by fabian2k | Hacker News Reader

NOT NULL really should be the default. There are of course valid reasons for allowing NULLs, but NOT NULL is much easier to handle for most cases. I don't think nullable columns indicate a problem with the data, but nullable columns that don't have a good justifications are certainly trouble.

View on HN

The fun bit is this mistake gets replicated in every definition langage, sometimes made ever worse (e.g. openapi where fields can be omitted by default, and you can additionally make them nullable).

Different null types are the worst :(

One of the worst offenders was one API I was working with Optional<Something> could be null.

What is your solution for representing the difference between

{"foo": null} and {}

Because they are different, right?

Not parent, and not necessarily agree, but one should throw a parser/typecheck error and the other should not.

In cases where the field is required I would agree. But in the context of an update request, {"foo":null} and {} might both be valid with different semantics. "Update this field to null" vs "don't update this field"

A similar issue is {}, {"mylist": null} and {"mylist": []}. Three ways to represent a missing or empty list.

In Rust, I have occasionally seen things like:

   Option<Option<String>>

Here, "None" means "no value specified", and "Some(None)" means "a value is specified, and that value is null." And "Some(Some(my_string))" means the value is "my_string".

There are other ways to represent this in Rust, some of which might be clearer. This representation seems to be used most often if you have a type "MyType", and you want to automatically derive a type "MyTypePatch" using a macro.

That's also how I've seen it done. But that's not so different from the nullable optional approach. It's still effectively two flavors of null.

What I'm wondering is how people who have an issue with different representations of absence would approach (or avoid?) situations requiring them.

Larger enums to represent and discriminate. Null is just syntax sugar for the one-kind of absence case, and multiple-null-likes eliminates all benefits of that syntax sugar, so you might as well revert to a real discriminator.

Ideally you can force the use of the discriminator… but that depends on your type system

The problem with flattening the two absence cases into an enum is composability and generality because it forces the "outer null" case to intrude into concrete types. Say you have a key value mapping Map<String, T> and you represent changes to this map as Map<String, Option<T>>. One day T itself is Option<Int> so you end up Map<String, Option<Option<Int>>. If you want to use e.g. Option2 for that latter case you lose generality.

Where the "double absence" issue comes up in practice, it's usually in a context where it does make sense to represent and handle the first type of absence separately from the second type.

I don’t think default check constraints should be a part of any serious RDBMS. Developers are free to default to any behaviour they prefer.

Reply on news.ycombinator.com