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
{{ message }}
Repository navigation
Rows.Scan fails with Scanner objects, but Row.Scan works ok with Scanner objects. #1505
If I use scanner objects with Rows.Scan, the src argument is a []uint8 for all types.
Example code
My table is
CREATETABLEIF NOT EXISTS fruits (
id BIGINT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(45),
year SMALLINT,
amount INT,
price FLOAT(23),
PRIMARY KEY (id)
) ENGINE=InnoDB CHARSET=utf8mb4;
This shows that Row.Scan works with Scanner objects. However, Rows.Scan fails:
rows, err:=db.Query("select * from fruits;")
// err is nildeferrows.Close()
forrows.Next() {
err:=rows.Scan(id_scanner, name_scanner, year_scanner, amount_scanner, price_scanner)
// err is nil, but output is wrong
}
For the Id field, the value 49 is the ASCII '1'.
For the Name field, the value [97 112 112 108 101] is ASCII apple.
For the Year field, the value [49 57 54 53] is ASCII 1965.
For the Amount field, the value [49 50 51] is ASCII 123.
For the Price field, the value [55 46 53 53] is ASCII 7.55.
It looks like the src argument is the result of fmt.Print or something similar if Scanner objects are involved.
Configuration
This Scanner code works with Microsoft SQL Server. But it doesn't work with MySQL and I am testing the Scanner code against the mysql:8..0.31 docker image with go-1.20 on archlinux. My go.mod shows I am using github.com/go-sql-driver/mysql v1.7.1.
Using the delve debugger, I dug into the go-sql-driver code and discovered that Row.Scan calls binaryRows.Next and Rows.Scan calls textRows.Next. This explains why QueryRow returns the correct types but Query returns []uint8 for all columns. The question now is why Rows.Scan doesn't call binaryRows.Next as well. I will dig on.
My original code, which makes use of Query produces the wrong results.
// Query will call the go-sql-driver's textRows.Next function, which presents []uint8 (strings) to all the scanners.rows, err:=db.Query("select * from fruits;")
// err is nildeferrows.Close()
forrows.Next() {
err:=rows.Scan(id_scanner, name_scanner, year_scanner, amount_scanner, price_scanner)
// err is nil, but output is wrong
}
But I can get the right output with Prepare, calling Query via the statement object.
statement, err:=db.Prepare("select * from fruits;")
// err is nirows, err:=statement.Query()
// err is nildeferrows.Close()
forrows.Next() {
err:=rows.Scan(id_scanner, name_scanner, year_scanner, amount_scanner, price_scanner)
// err is nil, and output is the same as that produced by Row.Scan
}
The mysqlConn.queyy returns textRows while mysqlStmt.query returns *binaryRows.
Activity
Fung-Chai commentedon Oct 25, 2023
Using the
delvedebugger, I dug into thego-sql-drivercode and discovered thatRow.ScancallsbinaryRows.NextandRows.ScancallstextRows.Next. This explains whyQueryRowreturns the correct types butQueryreturns[]uint8for all columns. The question now is whyRows.Scandoesn't callbinaryRows.Nextas well. I will dig on.Fung-Chai commentedon Oct 25, 2023
Another discovery.
My original code, which makes use of
Queryproduces the wrong results.But I can get the right output with
Prepare, callingQueryvia the statement object.The
mysqlConn.queyyreturnstextRowswhilemysqlStmt.queryreturns *binaryRows.methane commentedon Oct 25, 2023
Using placeholder makes your query binary.
When implementing Scanner, you should expect many
driver.Valuetype input, not single consistent one.See #1452 for mitigations implemented in next release.