Re: [eclipselink-users] Strange Lob behavior

[Tom Ware <tom.ware@xxxxxxxxxx>]

Hi Laird,

  For a non-native query, we have the datatype in the object.  We will always 
try to convert to that type.

  For a native query, we do not have that information.  We have chosen some 
datatypes to convert and have not, yet, picked a type for LONGVARCHAR.

  As for the spec, you would have to take that up with the spec-committee. 
There would likely be some utility in providing a mechanism to make what comes 
back for a native query more consistent, but I'm not sure I'd consider it a hole.


-Tom

On 12/04/2013 10:05 AM, Laird Nelson wrote:
> On Fri, Apr 12, 2013 at 6:58 AM, Laird Nelson <ljnelson@xxxxxxxxx
> <mailto:ljnelson@xxxxxxxxx>> wrote:
>
>     On Fri, Apr 12, 2013 at 5:41 AM, Tom Ware <tom.ware@xxxxxxxxxx
>     <mailto:tom.ware@xxxxxxxxxx>> wrote:
>
>            Currently we do not convert LONGVARCHAR to a string type.
>
>
>
> (Pressed Send too early.)
>
> One other data point here that is a little odd.
>
> My colleague tells me that the behavior is different depending on the query
> mechanism.
>
> So if he does this:
>
> em.createQuery("SELECT h.foo FROM Hork h"); // JPQL, not SQL; assume mappings
> are correct
>
> ...and "foo" is an Informix TEXT field where the driver classifies it as a
> java.sql.Types#LONGVARCHAR and returns a byte[] natively, he says he gets back a
> List<Object[]> (which I'd expect), but the zeroth (and only) element of the
> Object[] is (wait for it) the string representation of the data.
>
> If he does this (the same stuff from my earlier emails):
>
> em.createNativeQuery("SELECT foo FROM Hork"); // SQL, not JPQL
>
> ...then he gets back the hex representation of the byte array.
>
> As I file my bug report: shouldn't these be the same?  Or is the former using
> JPA mapping information to help decide how to convert the result?  Isn't it a
> hole in the spec that the latter has no way to help the EntityManager out with
> the type of "foo"?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users