On Fri, 4 Mar 2005, Michael Barker wrote:
> Attached is a patch for Blob and Clob support with JUnits.
>
I've finally gotten around to reviewing this. The real problem is how to
deal with Clobs and encodings. PostgreSQL doesn't really have any
specific character large object support and the jdbc driver just
layers the Clob type on the existing binary large objects. From
the server's perspective it is all just binary data which makes
things like length return a number of bytes instead of the number
of characters, at least for a multibyte encoding.
As I see it we've got a number of poor options:
1) Always use a single byte encoding (like US-ASCII) for storing data even
though this cannot store all characters.
2) Always use a multibyte encoding (like UTF-8) for storing data even
though this will break many length/positioning methods.
3) Allow the user to select the encoding via a URL parameter.
4) Use the database's server encoding even though this won't always have a
JVM equivalent.
5) Use the JVM's encoding.
3) Seems like the only way to really allow a user to pick their poison.
Anyone else have an opinion? I suppose we could move a lot of the large
object exection from the server to the JDBC driver so it could correctly
count characters, but that'd we quite a performance hit.
I've attached the version of the patch that I've adjusted slightly and
pretty much ignores encoding entirely.
Finally some technical comments on the original patch:
You shouldn't throw a SQLException without a SQL State. To help enforce
this we throw org.postgresql.util.PSQLException that doesn't have a
constructor without a SQL state aregument.
In the unit tests you write:
if (rs.next()) {
// do something
} else {
assertFalse("Message", true);
}
We don't use assertFalse in order to retain compatibility with junit 3.7.
Also this is written more clearly as:
assertTrue(rs.next());
// do something
Kris Jurka
