Skip to content
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

Merged
merged 4 commits into from Apr 5, 2019
Merged

pass unsigned int as it is without converting it to string #838

merged 4 commits into from Apr 5, 2019

Conversation

darren
Copy link
Contributor

@darren darren commented Jul 18, 2018

Description

it is not necessary to convert uint64 to string
related issue: pingcap/tidb#7089

Checklist

  • Code compiles correctly
  • Created tests which fail without the change (if possible)
  • All tests passing
  • Extended the README / documentation, if necessary
  • Added myself / the copyright holder to the AUTHORS file

Copy link
Member

@julienschmidt julienschmidt left a 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 {
Copy link
Member

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?

@julienschmidt
Copy link
Member

It seems like this doesn't work with Go 1.8: https://travis-ci.org/go-sql-driver/mysql/jobs/405365785#L607
We didn't drop 1.8 support yet, so for now this would require some version dependent code.

@darren
Copy link
Contributor Author

darren commented Jul 18, 2018

@julienschmidt

Regarding the building error, Let's hold this until we drop 1.8 support?

@methane
Copy link
Member

methane commented Apr 4, 2019

@darren Would you update this PR? We don't support Go 1.8 anymore.

@darren
Copy link
Contributor Author

darren commented Apr 4, 2019

@methane
All tests have passed.
I have no new changes for this PR.

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.

@methane methane merged commit d3a0b0f into go-sql-driver:master Apr 5, 2019
@methane
Copy link
Member

methane commented Apr 5, 2019

Thank you.

vmg added a commit to vmg/mysql that referenced this pull request Apr 23, 2019
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`.
julienschmidt pushed a commit that referenced this pull request Apr 23, 2019
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`.
@julienschmidt julienschmidt added this to the v1.5.0 milestone Jan 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants