How are you planning on supporting this? Is there going to be some internal changes in Hibernate to support them, or are you just going to add new Blob and Clob types?
There are two parts to this new functionality. Firstly, there is the existing (in CVS) BlobType and ClobType. (BlobType was created by Benoit Menendez and this has given me the inspiration for the rest of the implementation.) The existing functionality lets you retrieve and manipulate existing Clobs and Blobs (to an extent that varies depending upon JDBC driver support) but doesn't let you create new Blobs or Clobs. So what I plan are methods:
Hibernate.createBlob(byte[] bytes) Hibernate.createClob(String string)
That will let you obtain an instance of java.sql.Clob or java.sql.Blob that simply wraps a byte array or string. Then BlobType and ClobType will detect wrapper instances and use setBytes() / setString() instead of setBlob() / setClob().
By exposing the actual Clob or Blob object to the persistent class we let you do whatever the JDBC driver will let you do. For example, in the case of Oracle, you could cast it to OracleBlob.
I think that this is a really nice design. It seems to be efficient (we never load up the whole Blob or Clob into memory); we can pass instances of Blob or Clob from one persistent class to another; we can manipulate the Blob if that is supported by the driver.
What do you think?
Well, I like it in theory. That's more or less what I was trying to do when I tried to address this problem a couple months back. However, I'd bet that you'll be fielding lots of support questions because I'm pretty sure this won't work for some db's. I know it won't work in Oracle due to their JDBC drivers. Here's a summary of my discoveries:
1) I was under the impression that I could just use my own Clob implementation and call PreparedStatement.setClob. Unfortunately, this is not the case. Oracle JDBC will throw a ClassCastException if it doesn't get an oracle.sql.CLOB. Furthermore, to save a CLOB for the first time, the row needs to be created first, then you need to select the Clob object, and then finally you can write the data out to the db. This means that CLOB support is not going to be as simple as providing a ClobType.
2) In order to write to a Clob, it must first be retrieved with a SELECT .. FOR UPDATE statement, which means that we'd have to fool around with locking when writing Clobs.
3) I considered just using character streams, but then found that Oracle does not support this with their thin JDBC drivers. They have a nice warning about data corruption if you don't use their OCI driver for character streams.
Something else just occurred to me: supporting Clobs and Blobs in long transactions will get pretty tricky. They'll be under the similar restrictions as lazily loaded, except they pretty much die when you close the connection even if it was previously "loaded."
I'd be delirously happy if you found a way around all these limitations. Perhaps only Oracle users are affected by these problems... :(
-Mark
P/S - If you haven't already written your own ClobImpl, I can send you what I have as a starting point.
------------------------------------------------------- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
