MySQL Bugs: #19332: JDBC getString can return

Bug #19332	JDBC getString can return
Submitted:	25 Apr 2006 11:21	Modified:	1 Sep 2009 11:30
Reporter:	Andy Seaborne	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	Connector / J	Severity:	S4 (Feature request)
Version:	5.0.0	OS:	Any (Java)
Assigned to:		CPU Architecture:	Any

Description:
The JDBC ResultSet operation getString()

In the version 5.0.0-beta code base:
com.mysql.jdbc.ResultSet line: 3415:
For binary objects, it calls  obj.toString();

obj is a byte[].  If it is not serialized, or can't be deserialized, it calls .toString is which giving a string of the form: "[B@12d7a10"

How to repeat:
Insert bytes into a MEDIUMBLOB.
Get them back, call .getString().

Suggested fix:
Would it be better to call "new String(b)" and risk the character conversion? At leats this would attempt to return the actual data and not the stringified reference to the byte[] array.

i.e "return new String(byte[]obj) ;"

3.1 behaves the same way as 5.0.0 but it appeats that 3.0 drivers did return a string of the bytes at this point.

(There are many issues to do with character encoding here - this suggestion is for the behaviour when, effectively, the application and the database are not perfectly matched - in our case, having to handle multiple character sets. in the same DB column.)

We had more issues when we did what you propose in 3.0 when users didn't understand why certain Strings worked okay, and others got corrupted.

If you're storing multiple character sets in MySQL in some sort of LOB, you're much better off with *TEXT with a character encoding of UTF-8, because in JDBC, that's the "correct" mapping of a LOB that has string-y characteristics. That's especially true with MySQL because there is definitely a characeter encoding in place (even if it's UTF-8) that comes "along for the ride" with the TEXT column types.

If we were going to follow the JDBC specification to the _letter_ in this case, we should really be throwing an exception, as *BLOB or  is not allowed to be converted to a String via ResultSet.getString().

For more details see B-6 in the JDBC-3.0 specification (page 182)

One note in that JDBC doesn't allow CLOB to String via getString(), but what we do have with the TEXT types is that it's a LOB _with_ a character encoding. BLOBs don't have a character encoding at all, by definition.

Mark - thanks for the reply.

If you had issues when it had the 3.0 behaviour (can't win!) then an exception would be good as well - what I found unexpected was getting back a string but it was "[B@12d7a10" (the .toString() of the byte[]).

We are working round this (because we have to support 3.1 drivers and other databases) so this is more user feedback than a potential issue.