Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Strange Lob behavior 
Hi Laird,

  Currently we do not convert LONGVARCHAR to a string type.
We do have some handling of LONGVARBINARY that, in some cases, converts it explicitly to a byte[]. We might be able to do something similar for LONGVARCHAR - perhaps to give a char[] back or something like that.
You may also be able to affect this functionality in DatabasePlatform implementation. Try overriding this method:
getObjectFromResultSet(ResultSet resultSet, int columnNumber, int type, AbstractSession session) 

  Please feel free to file a bug.

-Tom

On 10/04/2013 3:30 PM, Laird Nelson wrote:

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

--
http://about.me/lairdnelson


_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Back to the top