Working with EclipseLink 2.3.2 and Informix 11.70 and the Informix 3.70.JC7 driver.
We have a column defined in the database as Informix type "text". (This is an Informix type that stores large textual objects, akin to a CLOB.) We store strings in there of completely unpredictable length. They could be staggeringly enormous. At any rate, what we put in there is text; nothing else.
This gets mapped by the Informix driver to java.sql.Types#LONGVARCHAR. Fine, whatever; seems sound; completely under the control of the JDBC driver.
If you do someResultSet.getObject(columnIndex), you get back a byte[]. O...K, a little odd, would have expected a Reader or a String or a char[], but I could see that the "text" data type smells "large objectish", so perhaps that's OK. At any rate, we can't do anything about it.
OK, now for the EclipseLink part.
We have a native query like this:
final Query q = em.createNativeQuery("SELECT theColumnInQuestion FROM theTable");
assert q != null;
final List resultList = (List<String>)q.getResultList(); // regrettably the cast/lack of type info is present in the code with the issue; left it here in case it matters
assert resultList != null;
for (final String s : result) {
System.out.println("Result: " + s);
}
EclipseLink causes the value of "s" to be a long hex string, which is exactly the hex representation of the bytes returned by the JDBC driver. Hibernate returns the actual string.
It appears to me that somewhere EclipseLink has called resultSet.getObject(1), and has gotten back a byte[]. Then it seems that perhaps ignoring the LONGVARCHAR type information that is also part of the result set metadata, it sets about trying to come up with some kind of string representation for a byte array. Obviously the most general purpose such representation would be a hex string.
My question: is this all by design, or should I file a bug? It seems to me that if there's information present that can steer EclipseLink in a textual direction (java.sql.Types#LONGVARCHAR) it should take that into consideration when converting the value received by the JDBC driver.
Best,
Laird
