Explain low-level protocol leaky abstractions

[xaprb]

Drivers can implement some level of convenience, but ultimately the user can still be exposed to the low-level way the data is transmitted in the driver. For example, the mysql driver will do a strconv.ParseXXX to scan into integers and floats and so on, which avoids some code in your application sometimes. But it is still possible for users to see the differences in binary versus textual protocol; see for example go-sql-driver/mysql#211

[arnehormann]

Do you know of other specific problems for different RDBMSes? To me, only sql.Results on PostgreSQL comes to mind (you only get last_insert_id and rows_changed when you run it as Query instead of SELECT and have to append something to your query which is hard to do mechanically). But I lack experience in anything but MySQL...
It would be nice to describe driver specifics for more than just mysql so this stays a tutorial that can generally be used and is not just about MySQL.

Also, we don't use strconv (not anywhere as far as I can see at a glance).
And sometimes we jump through strange hoops to get a little more performant. Case in point:
https://github.com/go-sql-driver/mysql/blob/master/utils.go#L441
https://github.com/go-sql-driver/mysql/blob/master/utils.go#L468
https://github.com/go-sql-driver/mysql/blob/master/utils.go#L512

[xaprb]

Oh, I didn't realize that you don't use strconv. I guess the database/sql
does that internally, then, because in MySQL for example, SHOW STATUS
returns two columns. First is name, second is value, which is usually a
number. If you do this,

var name string
var value float64
err := rows.Scan(&name, &value)

On some of the rows you'll get a strconv error -- for the rows where the
status variable isn't a number.

[arnehormann]

SHOW STATUS returns a number in the second column?
Only for some of the columns, right?
An example: Slave running is OFF on my local installation.
And the type stays the same for all rows, so string would be a safe bet there.

[arnehormann]

another one: Innodb_buffer_pool_dump_status is not started

[xaprb]

Right. Here's what I mean: most of the time, there is a number (in string
form) in the second column. If I want to treat it as a number in my code, I
can do one of two things:

1. Scan it into a string, then strconv.ParseFloat() or whatever.
2. Scan it right into a float. Somewhere (I guess in the database/sql
   layer) the strconv stuff is called for me.

I discovered this by accident. It cleans up my client code a lot. All I
have to do is check for err on Scan(), and if there's a number-parsing
error, discard that row. Might be nice to explain this in the tutorial.

[arnehormann]

Yea, that's
http://golang.org/src/pkg/database/sql/sql.go?#L1595
calling
http://golang.org/src/pkg/database/sql/convert.go#L85
😀