You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2017/11/02 02:37:13 error: sql: Scan error on column index 1: converting driver.Value type ("") to a float64: invalid syntax
2017/11/02 02:37:13 error: sql: Scan error on column index 0: converting driver.Value type ("") to a float64: invalid syntax
This issue arises because we assume that data will never be nil and automatically convert it to a string to be parsed by strconv as in
The above can be fixed if we detect that the byte slice of the representative data is nil and automatically set that to zero like in this patch
diff --git a/src/database/sql/convert.go b/src/database/sql/convert.go
index b79ec3f..bb384a9 100644
--- a/src/database/sql/convert.go+++ b/src/database/sql/convert.go@@ -402,11 +402,15 @@ func convertAssign(dest, src interface{}) error {
dv.SetUint(u64)
return nil
case reflect.Float32, reflect.Float64:
- s := asString(src)- f64, err := strconv.ParseFloat(s, dv.Type().Bits())- if err != nil {- err = strconvErr(err)- return fmt.Errorf("converting driver.Value type %T (%q) to a %s: %v", src, s, dv.Kind(), err)+ var f64 float64+ if src != nil {+ var err error+ s := asString(src)+ f64, err = strconv.ParseFloat(s, dv.Type().Bits())+ if err != nil {+ err = strconvErr(err)+ return fmt.Errorf("converting driver.Value type %T (%q) to a %s: %v", src, s, dv.Kind(), err)+ }
}
dv.SetFloat(f64)
return nil
or a similar patch that avoids passing in "", "", "NULL" into strconv.
Could we recognize the special case when the column value is NULL thus a nil byte slice, and instead of passing it into strconv, just set that to the zero value?
This issue kept me up as I thought there was some other issue with my database and code so I went on a digging expedition, it has bitten me in the past as well and I suspect that other folks have experienced it before.
I believe that this is a bug, but since it has been this behavior has existed for ages, I'll title this as a proposal.
The text was updated successfully, but these errors were encountered:
IMO, silently converting NULL to a float64/int64 zero value is a recipe for disaster. It goes directly against the purpose why databases have the concept of NULL in the first place. Users should use sql.NullFloat64 or sql.NullInt64 etc. instead where column values may be NULL.
@cznic and @rsc thank you for the input and yeah it makes sense that we have sql.NullInt64 et al, implementing sql.Scanner. It just seems odd to me that I have to radically modify my structs' fields in order to use successfully sql.Scan moreover on fields that may or may not be NULL. I think I'll just replace all my structs with the respective sql.Scanner implementing types. TIL :)
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?What did you do?
You'll need a MySQL server and then run the code below.
and the respective MySQL table looks like this
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link, sure: https://gist.github.com/odeke-em/78a237c1b4788ad36162c47e5903217a
What did you expect to see?
Successfully ran
What did you see instead?
This issue arises because we assume that data will never be nil and automatically convert it to a string to be parsed by strconv as in
go/src/database/sql/convert.go
Lines 404 to 405 in 0d101d1
The above can be fixed if we detect that the byte slice of the representative data is nil and automatically set that to zero like in this patch
or a similar patch that avoids passing in "", "", "NULL" into strconv.
Could we recognize the special case when the column value is NULL thus a nil byte slice, and instead of passing it into strconv, just set that to the zero value?
This issue kept me up as I thought there was some other issue with my database and code so I went on a digging expedition, it has bitten me in the past as well and I suspect that other folks have experienced it before.
I believe that this is a bug, but since it has been this behavior has existed for ages, I'll title this as a proposal.
The text was updated successfully, but these errors were encountered: