Skip to content

Expose mysql info from ok packets #180

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

Closed
enknamel opened this issue Dec 3, 2013 · 5 comments
Closed

Expose mysql info from ok packets #180

enknamel opened this issue Dec 3, 2013 · 5 comments

Comments

@enknamel
Copy link

enknamel commented Dec 3, 2013

I am not sure if this is possible with the current go database library (unless you do some terrible hack) but I would love to be able to make use of the info string at the end of the ok packet since it can can contain some very useful data such as rows matched. Would this be possible to do?

@arnehormann
Copy link
Member

We'll have to discuss this, it really doesn't fit as is. I'm guessing it won't land in the immediate future, but don't give up yet...

@julienschmidt
Copy link
Member

The number of rows matched is available at least for Exec: https://github.com/go-sql-driver/mysql#clientfoundrows

Exposing additional data is very hard, since we can not define new functions on Result or Rows.
The database/sql package wraps the structs returned by the driver. With the current implementation it is impossible to get a reference to the mysqlRows wrapped by sql.Rows in a sensible way.

@arnehormann managed to get it via reflection, but this might break with any change in the database/sql package. I do not want to include unstable stuff like this in the driver.

@arnehormann
Copy link
Member

@julienschmidt I think what he wants is a string never even read which would be read at the end of this function: https://github.com/go-sql-driver/mysql/blob/master/packets.go#L484 (string info, payload after warning count).

There's no way to get that with reflection and that's not what I did.

Still, I fully intend to write a CL for Go to fix https://code.google.com/p/go/issues/detail?id=5606 as soon as the current freeze is lifted. That would make my sqlinternals package obsolete.

@julienschmidt
Copy link
Member

I'm assuming we would read and store it somewhere in Result / Rows

@arnehormann
Copy link
Member

Ah - I missed that you assumed an already changed function which stored it.

I thought about an api that gives access or hooks into the low level []byte of a packet - without additional parsing for the driver itself. That could lead to corruption and memory problems, but that's on the user of that api.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants