db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From V Narayanan <V.Naraya...@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:58:45 GMT
Knut Anders Hatlen wrote:
> 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.
>   

This seemed a good way to me too. I will wait until tomorrow to see if 
people have more views. If there is no objection I will proceed with a).

Thank you for the quick response.

Narayanan


Mime
View raw message