I guess the problem may be solved when all drivers implement the JDBC standard for writing CLOB/BLOB data. In the meantime, I had submitted a patch for writing CLOB data for Oracle. I tested it with the OJB blob test code and it seemed to work fine for me. I am using the Oracle OCI8 driver. So, I do not know if it will work for the Oracle thin driver.
----- Original Message ----- From: "Matthew Baird" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Friday, November 22, 2002 1:58 PM Subject: RE: [PATCH]Re: null value for Blob/Clob causes NullPointerException > the problem I see with this is, you could write an oracle specific blob/clob implementation and put it in the platform impl, but in a lot of cases that would be specific to the driver and not necessarily Oracle. > > The solution would be to have a driverplatform, which isn't a good idea either as many jdbc classes are wrapped (both by ojb and potentially by your app server, say Jboss). There is not a reliable way to find out what the driver is, and therefore cast to the appropriate ORACLE jdbc type to accomplish the insertion. > > I haven't seen anyone do a great job with this. > > m > > > -----Original Message----- > From: Michael Mogley [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 1:38 PM > To: OJB Users List > Subject: Re: [PATCH]Re: null value for Blob/Clob causes > NullPointerException > > > Russell, > > Thanks for addressing this so quickly. > > Another thing I'm concerned about is how Ojb handles LOBs that are larger > than 4K - particularly for insert/update. On Oracle, I know that a SELECT > FOR UPDATE is required on the LOB field, after which an OutputStream is > opened and written to. At least this is what I have had to do with the > 8.1.7 thin drivers. > > I have found that attempting to store a string directly using the > conventional PreparedStatement.set(int, Object) method causes it to be > truncated after 4K. > > I'll do some tests today to see what the case is with Ojb. Just wanted to > give you a heads-up on the issue. > > Michael > > ----- Original Message ----- > From: "Russell Smyth" <[EMAIL PROTECTED]> > To: "'OJB Users List'" <[EMAIL PROTECTED]> > Sent: Friday, November 22, 2002 10:41 AM > Subject: RE: [PATCH]Re: null value for Blob/Clob causes NullPointerException > > > > I am sorry, I did not realize you do not know how to read or apply a > patch. > > The code you > > quote is the original, un-patched code. Let me walk you through the patch. > > > > (PATCH HEADER INFO - DESCRIBES THE PATCH) > > Index: src/java/org/apache/ojb/broker/accesslayer/JdbcAccess.java > > > > =================================================================== > > RCS file: > > > /home/cvspublic/jakarta-ojb/src/java/org/apache/ojb/broker/accesslayer/JdbcA > > ccess.java,v > > retrieving revision 1.21 > > diff -u -r1.21 JdbcAccess.java > > --- src/java/org/apache/ojb/broker/accesslayer/JdbcAccess.java 14 Nov 2002 > > 20:28:20 -0000 1.21 > > +++ src/java/org/apache/ojb/broker/accesslayer/JdbcAccess.java 22 Nov 2002 > > 05:08:08 -0000 > > @@ -582,13 +582,13 @@ > > (SOME CONTEXT TO SEE WHERE THE PATCH GOES, AND TO ALLOW THE PATCH TOOL TO > > INTEGRATE THE CHANGE - THIS "UN MARKED" CODE IS COMMON TO BOTH BEFORE AND > > AFTER) > > case Types.CLOB : > > { > > java.sql.Clob aClob = rs.getClob(columnId); > > (A "REMOVE LINE" INDICATOR, MEANING REMOVE THIS LINE FROM THE ORIGINAL, AT > > THIS POSITION) > > - result = aClob.getSubString(1L, (int) > aClob.length()); > > (A "ADD LINE" INDICATOR, MEANING ADD THIS LINE TO THE ORIGINAL, AT THIS > > POSITION) > > + result = ( rs.wasNull() ? null : > aClob.getSubString(1L, > > (int) aClob.length()) ); > > break; > > } > > case Types.BLOB : > > { > > java.sql.Blob aBlob = rs.getBlob(columnId); > > - result = aBlob.getBytes(1L, (int) aBlob.length()); > > + result = ( rs.wasNull() ? null : aBlob.getBytes(1L, > > (int) aBlob.length()) ); > > break; > > } > > default : > > > > > > I hope this clears things up for you. As you can see, in my code > > result = ( rs.wasNull() ? null : aClob.getSubString(1L, (int) > > aClob.length()) ); > > we do nothing with the blob/clob if it is null, just return null! > > > > Russell > > > -----Original Message----- > > > From: Rajeev Kaul [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, November 22, 2002 11:35 AM > > > To: OJB Users List > > > Subject: Re: [PATCH]Re: null value for Blob/Clob causes > > > NullPointerException > > > > > > > > > Your code will crash at the point where you are using the > > > clob/blob object > > > without checking if it is null. For example, at the > > > following statement: > > > > > > result = aClob.getSubString(1L, (int) > > > aClob.length()); > > > > > > Now, I have not checked what happens if the CLOB field is of > > > zero length but > > > not null. If it is possible to have a zero-length CLOB field > > > then we just > > > check for CLOB object being null and remove the check for its length. > > > > > > ----- Original Message ----- > > > From: "Russell Smyth" <[EMAIL PROTECTED]> > > > To: "'OJB Users List'" <[EMAIL PROTECTED]> > > > Sent: Friday, November 22, 2002 10:21 AM > > > Subject: RE: [PATCH]Re: null value for Blob/Clob causes > > > NullPointerException > > > > > > > > > > I fail to se how your change is different, except that your > > > change will > > > > leave the return value as null if the CLOB/BLOB length is 0 > > > - which I > > > think > > > > is incorrect. > > > > If the db reports that the CLOB/BLOB is there but empty, > > > then it is NOT > > > > null. > > > > > > > > my change returns null if the db reports null, and reports > > > the value of > > > the > > > > BLOB/CLOB as reported by the db if not null. > > > > > > > > Your other changes I would have to look through the sources > > > to see what > > > you > > > > intend. Diffs would be much easier to read here! > > > > > > > > -----Original Message----- > > > > From: Rajeev Kaul [mailto:[EMAIL PROTECTED]] > > > > Sent: Friday, November 22, 2002 11:11 AM > > > > To: OJB Users List > > > > Subject: Re: [PATCH]Re: null value for Blob/Clob causes > > > NullPointerException > > > > > > > > > > > > I do not think your patch addresses the problem of either > > > CLOB or BLOB > > > > object being null. The fix that worked for me is shown below: > > > > > > > > case Types.CLOB : > > > > { > > > > java.sql.Clob aClob = rs.getClob(columnId); > > > > if (aClob != null && aClob.length() > 0) > > > > { > > > > result = > > > > aClob > > > > .getSubString(1L, (int) > > > aClob.length()) > > > > .toCharArray(); > > > > } > > > > break; > > > > } > > > > case Types.BLOB : > > > > { > > > > java.sql.Blob aBlob = rs.getBlob(columnId); > > > > if (aBlob != null && aBlob.length() > 0) > > > > { > > > > result = aBlob.getBytes(1L, (int) > > > aBlob.length()); > > > > } > > > > break; > > > > } > > > > > > > > > > > > I had earlier submitted fixes for other CLOB issues. I am > > > resending them > > > in > > > > case somebody finds them useful. > > > > > > > > To fix the problem, I made the following changes: > > > > > > > > 1. Modified ojbtest_schema.xml BLOB_TEST table to (the > > > changes are shown > > > in > > > > Red). > > > > > > > > <table name="BLOB_TEST"> > > > > <column name="ID" required="true" primaryKey="true" > > > type="INTEGER"/> > > > > <column name="BLOB_VALUE_" type="BLOB"/> > > > > <column name="CLOB_VALUE_" type="CLOB"/> > > > > </table> > > > > > > > > 2. Modified the setObjectForStatement method of > > > PlatformOracleImpl class > > > to > > > > write CLOB data as shown below: > > > > > > > > > > > > public void setObjectForStatement(PreparedStatement ps, int > > > index, Object > > > > value, int sqlType) throws SQLException > > > > > > > > { > > > > > > > > if (((sqlType == Types.VARBINARY) || > > > > > > > > (sqlType == Types.LONGVARBINARY) || > > > > > > > > (sqlType == Types.BLOB)) && > > > > > > > > (value instanceof byte[])) > > > > > > > > { > > > > > > > > byte buf[] = (byte[])value; > > > > > > > > ByteArrayInputStream inputStream = new > > > ByteArrayInputStream(buf); > > > > > > > > changePreparedStatementResultSetType(ps); > > > > > > > > ps.setBinaryStream(index, inputStream, buf.length); > > > > > > > > } > > > > > > > > else if (sqlType == Types.CLOB) > > > > > > > > { > > > > > > > > CharArrayReader inputStream = new > > > CharArrayReader((char[]) value); > > > > > > > > ps.setCharacterStream(index, inputStream, > > > ((char[])value).length); > > > > > > > > } > > > > > > > > else if (value instanceof Double) > > > > > > > > { > > > > > > > > // workaround for the bug in Oracle thin driver > > > > > > > > ps.setDouble(index, ((Double) value).doubleValue()); > > > > > > > > } > > > > > > > > else > > > > > > > > { > > > > > > > > super.setObjectForStatement(ps, index, value, sqlType); > > > > > > > > } > > > > > > > > } > > > > > > > > 3. In JdbcAccess class modified the getObjectFromColumn method for > > > CLOB/BLOB > > > > to what is shown at the top of this e-mail. > > > > > > > > > > > > > > > > The CLOB should return an object of type char[] to be > > > consistent with > > > BLOBs > > > > returning objects of type byte[]. However, it is not > > > mandatory to do so. > > > > We could leave this as is, and modify the CLOB fields in > > > corresponding > > > > classes to be of type String. That is, for example, the > > > ObjectWithBlob > > > > class will have to be modified to have the clob property > > > defined as a > > > > String. But if we make the change shown above, you do not > > > have to modify > > > > the ObjectWithBlob class - the clob property can remain as character > > > array. > > > > > > > > > > > > ----- Original Message ----- > > > > From: "J. Russell Smyth" < <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]> > > > > To: "OJB Users List" < <mailto:[EMAIL PROTECTED]> > > > > [EMAIL PROTECTED]> > > > > Sent: Thursday, November 21, 2002 9:51 PM > > > > Subject: [PATCH]Re: null value for Blob/Clob causes > > > NullPointerException > > > > > > > > > > > > > We just happened to also run into that today. > > > > > > > > > > Attatched is a patch to fix, and a patch to the test case > > > for blobs to > > > > > verify the fix. Unfortunately HSQLDB does not support the blob > > > > > functions, hence this test is commented out of AllTests, > > > and I do not at > > > > > the moment have access to my other db's to run this test. > > > However, it > > > > > should be good. > > > > > > > > > > On Thu, 2002-11-21 at 20:11, Michael Mogley wrote: > > > > > > I've just started experimenting with Ojb and seem to > > > have run across a > > > > bug. Specifically, a Clob or Blob field whose value is > > > undefined in the > > > db > > > > gives the following stack trace: > > > > > > > > > > > > java.lang.NullPointerException > > > > > > at > > > > > > > org.apache.ojb.broker.accesslayer.JdbcAccess.getObjectFromColu > > > mn(JdbcAccess. > > > > java:592) > > > > > > at > > > > > > > org.apache.ojb.broker.accesslayer.JdbcAccess.getObjectFromColu > > > mn(JdbcAccess. > > > > java:469) > > > > > > at > > > > > > > org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readObj > > > ectArrayFrom(R > > > > owReaderDefaultImpl.java:141) > > > > > > at > > > > > > > org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResu > > > ltSet(RsIterat > > > > or.java:385) > > > > > > at > > > > > > > org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:203) > > > > > > at > > > > > > > org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollec > > > tionByQuery(Pe > > > > rsistenceBrokerImpl.java:1117) > > > > > > at > > > > > > > org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollec > > > tionByQuery(Pe > > > > rsistenceBrokerImpl.java:1239) > > > > > > at > > > > > > > org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollec > > > tionByQuery(Pe > > > > rsistenceBrokerImpl.java:1265) > > > > > > at > > > > > > > org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollec > > > tionByQuery(Pe > > > > rsistenceBrokerImpl.java:1252) > > > > > > > > > > > > Ojb attempts to perform operations on the Blob/Clob > > > before checking to > > > > see if the returned value is null. > > > > > > > > > > > > Or am I missing something? > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____ > > > > > > > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: < > > > > <mailto:[EMAIL PROTECTED]> > > > > mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: < > > > > <mailto:[EMAIL PROTECTED]> > > > > mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
