8 ms·

>nullable types are converted into their default value in golang This just seems...wrong. Why would the column be nullable if you don’t actually care if it’s N

by wrs 7y ago

>nullable types are converted into their default value in golang This just seems...wrong. Why would the column be nullable if you don’t actually care if it’s NULL?

pxue 7y ago
Follow up questions: if I read out a nullable text field and write the same struct back into the database is it going to insert an empty string into that column? Also related, how would auto incr pk work?
- kodebrew 7y ago
  Yes I think it would insert an empty string. I think all the tests are using uuid's as primary keys, this is a good point -- thanks for raising.
  - noir_lord 7y ago
    That would be horrible if you had other systems that predated and did depend on the null (you could argue they shouldn't do that but well shouldn't and didn't aren't the same thing alas).
    - caesarshift 7y ago
      Why is NULL a bad thing? Sometimes I absolutely want to know if a field is NULL, so i can coalesce to the desired value. I know this is SQL Server specific, since Oracle treats empty strings and NULLs the same, but that approach has always felt wrong to me. Thoughts? Edit: I see maybe that I should have scrolled down further before posting this. Lots of discussion further down about NULL values.
  - redis_mlc 7y ago
    Using UUIDs as a primary key is considered an anti-pattern from space and performance standpoints. You should use UUIDs only when, you know, you need a UUID.
pushpop 7y ago
In my experience most of the time a field is nullable it’s by accident. Some RDBMS and/or SQL “IDEs” default to allowing null too, which doesn’t help matters. Personally I think NULL shouldn’t be supported unless the developer categorically sets a “yes, I actually do want this archaic option enabled” flag in their DB backend. Edit: getting a lot of heat for this comment from people misunderstanding it. I’m not saying “null” shouldn’t exist, just that it shouldn’t be the default. Side point: most of the time people think they need null they don’t.
- camdenlock 7y ago
  “Unset” is an extremely valuable state to be able to check. It’s why we have null/nil in well-designed languages. The zero value of a golang int is not the same as indicating a lack of presence. There are plenty of scenarios where “unset” is a necessary state vs the zero value.
  - pushpop 7y ago
    I agree however it is only valuable under specific circumstances while it can frequently create hidden traps. On balance it causes more problems than it solves. Which is why I suggested it should be an optional flag enabled on the backend rather than the default.
    - baq 7y ago
      Maybe/Option would be better. NULL is what we've got though. setting columns to not null is leaps ahead of most programming languages anyway.
    - peteretep 7y ago
      > On balance it causes more problems than it solves This is far from clear
      - pushpop 7y ago
        Like everything, it depends on your language and framework. But after 30 years of experience writing software in strictly typed languages, I’ve seen lots of people get caught out with nullable fields. However if you’re main body of experience is Perl (for example) then NULL isn’t ever an issue.
kodebrew 7y ago
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.
- vbezhenar 7y ago
  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.
- wrs 7y ago
  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.
- nerdponx 7y ago
  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.
Rapzid 7y ago
Go's defaults for types are great in a lot of go specific ways, but anyone who has dealt with needing to use pointers all over the place in DTOs knows how disgusting it can get.
- kodebrew 7y ago
  Agreed.

by wrs 7y ago

>nullable types are converted into their default value in golang This just seems...wrong. Why would the column be nullable if you don’t actually care if it’s NULL?

pxue 7y ago

Follow up questions: if I read out a nullable text field and write the same struct back into the database is it going to insert an empty string into that column? Also related, how would auto incr pk work?

kodebrew 7y ago
Yes I think it would insert an empty string. I think all the tests are using uuid's as primary keys, this is a good point -- thanks for raising.
- noir_lord 7y ago
  That would be horrible if you had other systems that predated and did depend on the null (you could argue they shouldn't do that but well shouldn't and didn't aren't the same thing alas).
  - caesarshift 7y ago
    Why is NULL a bad thing? Sometimes I absolutely want to know if a field is NULL, so i can coalesce to the desired value. I know this is SQL Server specific, since Oracle treats empty strings and NULLs the same, but that approach has always felt wrong to me. Thoughts? Edit: I see maybe that I should have scrolled down further before posting this. Lots of discussion further down about NULL values.
- redis_mlc 7y ago
  Using UUIDs as a primary key is considered an anti-pattern from space and performance standpoints. You should use UUIDs only when, you know, you need a UUID.

pushpop 7y ago

In my experience most of the time a field is nullable it’s by accident. Some RDBMS and/or SQL “IDEs” default to allowing null too, which doesn’t help matters. Personally I think NULL shouldn’t be supported unless the developer categorically sets a “yes, I actually do want this archaic option enabled” flag in their DB backend. Edit: getting a lot of heat for this comment from people misunderstanding it. I’m not saying “null” shouldn’t exist, just that it shouldn’t be the default. Side point: most of the time people think they need null they don’t.

camdenlock 7y ago
“Unset” is an extremely valuable state to be able to check. It’s why we have null/nil in well-designed languages. The zero value of a golang int is not the same as indicating a lack of presence. There are plenty of scenarios where “unset” is a necessary state vs the zero value.
- pushpop 7y ago
  I agree however it is only valuable under specific circumstances while it can frequently create hidden traps. On balance it causes more problems than it solves. Which is why I suggested it should be an optional flag enabled on the backend rather than the default.
  - baq 7y ago
    Maybe/Option would be better. NULL is what we've got though. setting columns to not null is leaps ahead of most programming languages anyway.
  - peteretep 7y ago
    > On balance it causes more problems than it solves This is far from clear
    - pushpop 7y ago
      Like everything, it depends on your language and framework. But after 30 years of experience writing software in strictly typed languages, I’ve seen lots of people get caught out with nullable fields. However if you’re main body of experience is Perl (for example) then NULL isn’t ever an issue.

kodebrew 7y ago

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.

vbezhenar 7y ago
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.
wrs 7y ago
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.
nerdponx 7y ago
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.

Rapzid 7y ago

Go's defaults for types are great in a lot of go specific ways, but anyone who has dealt with needing to use pointers all over the place in DTOs knows how disgusting it can get.

kodebrew 7y ago
Agreed.