-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
pass unsigned int as it is without converting it to string #838
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to finally remove this ugly workaround.
Please make an entry in the AUTHORS
file or let us know which existing entry applies to your contributions.
statement.go
Outdated
@@ -169,7 +168,7 @@ func (c converter) ConvertValue(v interface{}) (driver.Value, error) { | |||
case reflect.Uint64: | |||
u64 := rv.Uint() | |||
if u64 >= 1<<63 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason to still do this check for the high bit instead of just always returning u64
?
It seems like this doesn't work with Go 1.8: https://travis-ci.org/go-sql-driver/mysql/jobs/405365785#L607 |
Regarding the building error, Let's hold this until we drop 1.8 support? |
@darren Would you update this PR? We don't support Go 1.8 anymore. |
@methane I have tested against MySQL and TiDB, TiDB still got the unsigned bigint thing wrong in corner cases, I shall report again to TiDB once this PR get merged. |
Thank you. |
PR go-sql-driver#838 introduced a fix for the driver's custom Value Converter that stopped emitting large uint64 `driver.Value`s as a string. Instead, now _all_ uint{8,16,32,64} values passed to the driver are returned as uint64, and `packets.c` now explicitly handles `driver.Value` instances that are uint64. However, the update in `packets.c` only applies when sending `driver.Value` arguments to the server. When a connection is set up using `InterpolateParams = true` and query interpolation happens inside of the driver, the `(*mysqlConn) interpolateParams` does **not** handle uint64 values (which, again, are now passed by `database/sql` because we've updated our value converter to generate them). Because of this, any `DB.Query` operations which have an uint argument (regardless of its size!!) will force the driver to return `driver.ErrSkip`, disabling client interpolation for such queries. We can fix this by updating `interpolateParams` like we previously updated `writeExecutePacket`.
PR #838 introduced a fix for the driver's custom Value Converter that stopped emitting large uint64 `driver.Value`s as a string. Instead, now _all_ uint{8,16,32,64} values passed to the driver are returned as uint64, and `packets.c` now explicitly handles `driver.Value` instances that are uint64. However, the update in `packets.c` only applies when sending `driver.Value` arguments to the server. When a connection is set up using `InterpolateParams = true` and query interpolation happens inside of the driver, the `(*mysqlConn) interpolateParams` does **not** handle uint64 values (which, again, are now passed by `database/sql` because we've updated our value converter to generate them). Because of this, any `DB.Query` operations which have an uint argument (regardless of its size!!) will force the driver to return `driver.ErrSkip`, disabling client interpolation for such queries. We can fix this by updating `interpolateParams` like we previously updated `writeExecutePacket`.
Description
it is not necessary to convert uint64 to string
related issue: pingcap/tidb#7089
Checklist