[CONJ-987] Version 3.0.0 returns String for VARBINARY instead of byte[] as 2.7.6 did Created: 2022-07-04  Updated: 2022-07-20  Resolved: 2022-07-20

Status: Closed
Project: MariaDB Connector/J
Component/s: 2.7 compatibility
Affects Version/s: 3.0.6
Fix Version/s: 3.0.7

Type: Bug Priority: Major
Reporter: Jens Schauder Assignee: Diego Dupin
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes CONJ-989 Binary column read as String Closed
causes CONJ-991 Regression: binary(16) is returned as... Closed

 Description   

A query for a field of type VARBINARY used to return a byte[] up until version 2.7.6

It now returns a String.

Is this intentional? Or is this a regression?

 Comments   
Comment by Jens Schauder [ 2022-07-04 ]

There is a reproducer here https://github.com/schauder/issue-CONJ-987

Switching between the two driver versions in the POM demonstrate the change in behaviour when running the test.
It requires docker, since it uses Testcontainers for creating the database.

Comment by Jens Schauder [ 2022-07-04 ]

This issue blocks https://github.com/spring-projects/spring-data-relational/issues/1281

Comment by Russell Hunt [ 2022-07-06 ]

There are probably other changes required, but the primary change should be in getDefaultCodec() in
mariadb-connector-j/src/main/java/org/mariadb/jdbc/message/server/ColumnDefinitionPacket.java

It currently returns a StringCodec.INSTANCE for VARSTRING (and some other types).

SQL VARBINARY seems to be represented as a data type VARSTRING with charset 63 (binary) in the code.

Presumably, for VARSTRING (and STRING and others?) the method getDefaultCodec() should say:
"return isBinary() ? ByteArrayCodec.INSTANCE : StringCodec.INSTANCE;"

Comment by Diego Dupin [ 2022-07-20 ]

right, this is a clearly a regression, and Hunt correction is accurate. This will be part of next release 3.0.7 (before the end of the month).

Generated at Thu Feb 08 03:19:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.