-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: database/sql: support more nullable types #31231
Comments
I'd like to make a better API for passing values out and I've sketched some ideas out, but nothing final yet. If you want to make a case for having a NullRune type or if you want to do a survey of databases that support complex structures like JSON, please do so. I have other strategies I used to avoid these problems in general, so feedback on this area is great. Thanks! |
NullTime is on its way. The others seem very specialized. I don't even know how we would handle all structs. Note that for an arbitrary type T, the way to write sql.NullT is We can leave this on hold for generics but probably the answer is just use a pointer type. Those are nullable automatically. |
@kardianos the main internally-defined sql.Scanner/driver.Value type we use all over the place is NullInt32. This is because we want to use a 32-bit integer in our code for IDs which are 32 bits in the DB. So (in postgres):
(Naturally we prefer NullInt32 to turning a bunch of small integers into pointers.) |
Change https://golang.org/cl/174178 mentions this issue: |
I mailed a CL to support int32. I don't see any other nullable types being added as they are either specific to the database or uncommon. Int32 (INT or INTEGER) is commonly used in many databases and database schemas today. |
It is common for database integers to be represented as int32 internally. Although NullInt64 is already defined, this should remove some type casts and make working with those eaiser. For #31231 Change-Id: Ia0c37ecef035fee0734c1d1fb6f58aef6905cf5e Reviewed-on: https://go-review.googlesource.com/c/go/+/174178 Run-TryBot: Daniel Theophanes <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
I've closed this issue. I really can't see adding any other Nullable types in the Go std lib. If you think differently please open up a new issue showing how it will be useful on a type by type basis. |
why not add Nullable? type Nullable struct {
Value interface{}
Valid bool
}
func (s *Nullable) Scan(src interface{}) error {
if src == nil {
s.Valid = false
return nil
}
s.Valid = true
return convert.ConvertAssign(s.Value, src)
} |
@kardianos Hello. Why Value() in NullInt32 returns int64????? It's really strange. |
@nicola-spb As far as I can tell, it doesn't. Can you show your code or reproduce the issue? Or even link to the database/sql code that you are talking about? |
@kardianos golang 1.13 2177bfb#diff-5b3d7257e10f4efeecb9517a1b6d0c28R260 I use it like this
and wrap results from database
|
Don't use value method, that is for driver. Use field. |
I use sqlx. What is field? Can you give example please? |
Use https://godoc.org/database/sql#NullInt32.Int32 The field Int32 in the NullInt32 struct. |
Ok. Thank you. P.S. It's better of course. I rewrote functions. |
I'm not entirely sure why the database/sql package requires using special types to represent nullable fields, as opposed to plain old pointer types. Why don't all of the built-in Go types just feature sql.Scanner implementations, including arbitrarily deep pointers?
In any case, the API here is limited to a paltry set of types, compared to the full set of built-in types actually available to Go. We are missing nullable:
Sure, we can probably skip over complex numbers due to SQL generally not supporting complex numbers as standard types. But the aforementioned types are very common to use, so it would be better to round out the halfway marshaling and actually support these. As of now, users have to write a lot of custom code to manually marshal and truncate these types, with plenty of risk for error compared to built-in API's.
The text was updated successfully, but these errors were encountered: