After think, It is good idea to have CLOBS for VARCHARS, but to have any
chance:
How do You create this CLOB? If your column will be null you are in trouble,
as it will be impossible to call setClob(...) to set VARCHAR value. I mean
everyting will work until you will set/change values only by retrivied Clob
methods. You will be unable to set VARCHAR value with connection.createBlob,
too
You will need to ensure your VARCHAR will not be NULL, and your JPA will use
Clob.getter/Setter.
Andreas Joseph Krogh <andreak@officenet.no> Wednesday 09 February 2011
09:04:05
> On 02/09/2011 01:20 AM, Kris Jurka wrote:
> > On Mon, 7 Feb 2011, Andreas Joseph Krogh wrote:
> >> It's not clear to me why the JDBC-driver for PG shouldn't just use
> >> rs.getString() internally for getClob() calls? Requiring
> >> special-handling in Hibernate for dealing with Strings by setting an
> >> obscure property just doesn't seem right. And I don't want to set a
> >> property to handle CLOB which might affect how I use BLOBs.
> >
> > The problem is that we have no idea what someone might want to do with a
> > CLOB after they've fetched it. You're coming from the idea that all
> > they want to do is read it and copy the data out to a String. From that
> > perspective it's not hard to have a Clob wrapper around a String, but
> > what happens when they say clob.setString(13, "data")? Are we going to
> > try and figure out what row of what table that varchar column is coming
> > from and do a partial update on it?
>
> The javadoc for clob.setString(index, data) says:
> ----------------------------------------
> Writes the given Java String to the CLOB value that this Clob object
> designates at the position pos. The string will overwrite the existing
> characters in the Clob object starting at the position pos. If the end
> of the Clob value is reached while writing the given string, then the
> length of the Clob value will be increased to accomodate the extra
> characters.
>
> Note: If the value specified for pos is greater then the length+1 of the
> CLOB value then the behavior is undefined. Some JDBC drivers may throw a
> SQLException while other drivers may support this operation.
>
> Parameters:
> pos - the position at which to start writing to the CLOB value that this
> Clob object represents; The first position is 1
> str - the string to be written to the CLOB value that this Clob designates
> ----------------------------------------
>
> So, I think clob.setString(index, data) should behave just like
> StringBuilder.insert(int offset, String str) except overwrite existing
> data instead of moving the characters above the position.
