1. The type is merely a weak hint that you should check .Valid before you use the value, there's no enforcement: https://go.dev/play/p/nS8RxGujMBk
It's much better when the struct members are private and the only way to access the value is through a method that returns (value, bool):
if value, ok := optional.Get(); ok {
// value is valid
} else {
// value is invalid
}
2. We have generics now. Why use type-and-sql-specific wrappers when you could use a generic Option? Example implementation: https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e....
It’s also something I realized was lost in the JS progression towards Promise APIs and eventually async/await. Promises have ergonomic benefits over callback hell, but damn if the Node convention of cb: (error, result) => { /* … */ } wasn’t a Result type sitting there begging to be embraced. Again, not a Monad, but it’s a shame the good API design was thrown out with the inconvenient API design.
I'd say the opposite. I'd say it beats the hell out of Rust syntax, as Rust would force you to have staircase code here. No thank you.
Well, yeah, if something may or may not be there, you have to check before you use it. How else do people want it to work?
The salient rebuttal is that this pattern is a strong hint to check, whereas a pointer is ambiguous (it's unclear whether or not a bare pointer may ever be nil, but you would only use this pattern to be explicit that a check is needed). This pattern can also support value types so you don't have to worry as much about unnecessary allocations.
After using NULLs this way at first, I noticed it's generally much much easier for me to just avoid nullable SQL columns wherever possible (it was always possible so far). Most of the time there is a much easier was to say a value is empty. For strings '' for example.
This seriously made everything so much easier. Not necessarily anything to do with go tho.
Except inner joins and the like, I guess.
I hear this advice quite often, but that doesn't relief you of handling NULL values. E.g. a NOT NULL column can be NULL in a result of an outer join.
I have no idea what is the issue here?
It seems like the intent of a string pointer vs. `sql.NullString` is their goal with this type anyways[1]?
In practice I've used a string pointer when I need a nullable value, or enforce `NOT NULL` in the DB if we can't/don't want to handle null values. Use what works for you, and keep the DB and code's expectations in-sync.
[1]: https://groups.google.com/g/golang-nuts/c/vOTFu2SMNeA/m/GB5v...
type nullString struct {
s *string
}
func (ts nullString) Scan(value interface{}) error {
if value == nil {
*ts.s = "" // nil to empty
return nil
}
switch t := value.(type) {
case string:
*ts.s = t
default:
return fmt.Errorf("expect string in sql scan, got: %T", value)
}
return nil
}
func (n *nullString) Value() (driver.Value, error) {
if n.s == nil {
return "", nil
}
return *n.s, nil
}
var node struct { Name string }
db.QueryRow("select name from node where id=?", id).Scan(nullString(&node.Name))You could of course have an API that just returns a slice of "any", and conditionally check whether a value is of type "string" or "mylibrary.NullValue" after the fact. This isn't clearly better to me than the Scan API. You are going to have to eventually cast "any" to a real type in order to use it; with Scan the library does that for you.
Your own types can implement sql.Scanner to control exactly how you want to handle something. (Indeed, your "Scan" method receives something with type "any", and you need to check what the type is and convert it to your internal representation.)
Also wanted to throw this out here; you don't have to be satisfied with lossy versions of your database's built in types. Libraries like https://pkg.go.dev/github.com/jackc/pgtype@v1.11.0 will give you a 1:1 mapping to Postgres's types. (I'm sure other database systems have similar libraries.)