db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Difference in behaviour of Derby client and Embedded driver when doing a updateClob and a updateBlob
Date Thu, 08 Mar 2007 13:47:22 GMT
V Narayanan <V.Narayanan@Sun.COM> writes:

> Hi,
> I was working on implementing updateClob/updateBlob methods on the
> network client when I noticed the following.
>
> 1) updateClob on a CHAR/VARCHAR/LONG VARCHAR column throws an
> exception on the Embedded Driver but not on the NetworkClient
> 2) updateBlob works on a CHAR/VARCHAR/LONG VARCHAR FOR BIT DATA throws
> an exception on the Embedded Driver but not on the NetworkClient
>
> From what the JDBC 4.0 spec says (pg 198 table b-5) the Embedded
> behaviour seems to be correct.
>
> Also the current implementation of setObject(int targetType,
> java.sql.Clob source) in the client is bugged. In implementing
> updateClob(int , Clob) I forward this call to setObject. After this
> doing a updateClob on a CHAR column and a subsequent retrieval using
> ResultSet.getString gives
>
> "org.apache.derby.impl.jdbc.EmbedClob@147c1db"
>
> This is because we do a toString on the Clob column while doing an
> insert. The relevant code can be found in
>
> CrossConverters.java line no 813.
>
> I have two ways of going about my patch to implement the
> updateBlob/updateClob methods
>
> a) Match Embedded behaviour. This would involve throwing an exception
> in the cases mentioned above
> b) Retain current behaviour. This would involve fixing
> CrossConverters.java to retrieve the string from the Clob rather than
> doing a toString.
>
> I intend to proceed in one of the above ways.

I think a) is the best alternative. There is already a JIRA issue for
this: DERBY-1610 (Resolve difference of type compatibility between
Embedded and NetworkServer/NetworkDriver). Currently, it has resolved
the differences for PreparedStatement/CallableStatement.setXXX() and
ResultSet.getXXX(). Doing the same for ResultSet.updateXXX() would be
great.

-- 
Knut Anders

Mime
View raw message