commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liam Coughlin <lscough...@gmail.com>
Subject Re: [dbutils] QueryRunner.fillStatement and the null problem (long)
Date Mon, 09 Feb 2009 19:59:09 GMT
snip

>
>    int sqlType = Types.VARCHAR;
>    if (!pmdKnownBroken) {
>        try {
>            sqlType = stmt.getParameterMetaData().getParameterType(i+1);
>        } catch (Exception e) { pmdKnownBroken = true; }
>    }
>    stmt.setNull(i + 1, sqlType);
>
> Possibly we'd add a new argument to the QueryRunner constructor, allowing
> you to set pmdKnownBroken to true right away.
>
/snip

IMHO -- this is a good solution.  Taking advantage of JDBC 3.0 seems like it
would be the right direction to move in rather then implementing spotty
parameter type filler classes.



>
> OPEN QUESTIONS
>
> 1) Will caching this result work?  Will it impact thread-safety in some
> negative way?
>

a)  Yes it should work.
b) Yes it will have a thread safety issue -- you'll need to synchronize on
something when setting the pmdKnownBroken variable.


>
> 2) How do we distinguish between getParameterType failing due to an
> out-of-bounds index, vs. failing due to a broken JDBC driver?  Normally we
> could use ParameterMetaData.getParameterCount() ... does that work on
> Oracle?  I don't have an instance available to test.
>

ParameterMetaData.getParameterCount() works fine, and it works fine on
oracle a well.

Thanks for taking the time to summarize and propose a solution -- hopefully
someone will pick up on your work!

Cheers,
-L

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message