Solved, and a bug found! Re: JDBC question: Creating new arrays
От | Joe Tomcat |
---|---|
Тема | Solved, and a bug found! Re: JDBC question: Creating new arrays |
Дата | |
Msg-id | 1037239808.1318.466.camel@linux обсуждение исходный текст |
Ответ на | Re: JDBC question: Creating new arrays (Doug McNaught <doug@mcnaught.org>) |
Список | pgsql-general |
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?
В списке pgsql-general по дате отправления: