Hacker News Reader

Comment by kodebrew | Hacker News Reader

Maybe this is true? I may not have thought through the entire feature that carefully.

The initial thought behind it: Go programmers generally use values for scalars instead of pointers. Can we make an sql mapper that reflects that general practice?

Maybe the answer is no.

View on HN

There's an inherent semantic mismatch here. SQL scalars have a dimension (NULL) that Go scalars don't have, so Go scalars just don't have enough information to represent SQL values. You have to put that dimension somewhere. Rather than using Go's separate dimension of nil-ness of pointers, you could put it in a separate boolean return value, or wrap it in a struct (see C#'s Nullable<T>), or make it queryable with a separate method (like IsNull(index)). Whatever it is, it also has to be two-way, so you can write NULLs as well as read them.

For any practical usage, this is a fundamentally broken implementation.

I spend something like 10% of my working hours un-fucking data that was poisoned by lazy, inconsistent, and/or incorrect handling of missing data.

This is what makes Excel such a dumpster fire for handling data. It is absolutely the wrong decision to make any new piece of software that handles missing data like this.

Java JDBC use similar approach for primitive types and has method wasNull which returns true if the last retrieved value was actually null. I hate that approach, honestly, but that's from Java perspective, may be it's more natural for Go developers.

Reply on news.ycombinator.com