On Tue, 2002-11-12 at 17:39, Doug McNaught wrote:
> Then you probably need to wrap your Java array in an object that
> implements java.sql.Array so that the JDBC driver can talk to it.
> Shouldn't be hard.
That still doesn't make it driver-independent, does it?
Anyway, I found a simple solution that works easily with Postgres: The
way PreparedStatement.setArray(Array) works is that it actually gets
translated to PreparedStatement.setString(Array.toString()). The
Array.toString() method is very simple; it just makes a string that
looks like '{484,282,945}' (for an int[]) so I just turned my int[] into
such a string, and called PreparedStatement.setString(). This is a bit
of a hack, but it seems that there is no db-independent way to do this,
so I have no other options. If we need to move to some other db, this
shouldn't be hard to modify as needed.
There is one other problem, though: If I have an array with no
elements, then this operation:
Array array = resultSet.getArray(3);
Object o = array.getArray();
throws a Bad Integer exception. This seems like it must be a bug in the
JDBC. To get around it, I put the o = array.getArray() inside a try
block, and if throws an exception, I know that the array is
zero-length. This is clunky and it violates the principle of "Only use
exceptions for exceptional conditions" and probably has some performance
problems. It seems that array.getArray() should always be able to
return properly because that should be a class invariant.
Any suggestions on this?