commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: [dbutils] Outstanding issues against dbutils-1.1 as of Nov. 1, 2006
Date Thu, 02 Nov 2006 07:54:58 GMT
On 11/1/06, Alan Canon <> wrote:
> Apologies if this is a duplicate: I sent it in to the list earlier but
> didn't see it appear.

Thanks for this work Alan, it's made it a lot easier for me to dig into it.

> There are four "Major" issues listed against the 1.1 release of
> [dbutils].
> DBUTILS-1 BeanListHandler and BeanHandler fail to support
> java.sql.Date() The reporter of the bug supplied code to fix the issue.

I've posted an alternative patch - let me know what you think.

> DBUTILS-32 Tests fail to build under 1.6, and warning while compiling
> source Alan Canon has supplied code in a JIRA comment to eliminate the
> compiler errors and warnings under Java 6 SDK.


> DBUTILS-3 Setting bean properties fails silently Alan Canon has supplied
> code in a JIRA comment to throw a SQLException when the described
> condition occurs, according to a recommendation made in a previous
> comment.

Applied (accidentally with DBUTILS-32 because I applied the wrong
patch - sorry).

> DBUTILS-31 fillStatement setNull bug with the Derby JDBC driver Code is
> present in the bug description, however it appears to have been prepared
> to work against JDBC 3.0. The suggested patch uses
> java.sql.ParameterMetaData, not present in JDK 1.4.2. Comments on the
> bug suggest testing the JDBCMajor number to see what the JDBC version
> is, and acting accordingly. Additionally, another comment states the
> code would need to fall back to the JDBC 2.1 specification if the Oracle
> JDBC driver throws an exception. Francis Townsend and Henri Yandell
> posted comments recommending that this solution be put off for a future
> release.

I've removed the 1.1 fix-version in JIRA for this one.

> In addition, there are three "Minor" issues listed:
> DBUTILS-17 ScalarHandler subclasses that return Integers and Longs
> Sample implmentations are provided in the JIRA report. This also
> addresses issues present in DBUTILS-27.

I've done the work for this, but saved it as a patch (DBUTILS-17.patch).

I don't get why this solution is of use to the user, it just seems
that it would stop them having to cast to Number, and handle
converting a String to a number if a database returns a String.
Especially given that it's targetting the count(*)'s of the world, are
there databases that answer that with a String?

> DBUTILS-27 QueryRunner.count(String, ...) methods for SELECT COUNT(...)
> sql This one is an improvement with diffs provided. Henri Yandell
> recommended it for the 1.1 release in a comment.

I think I like this approach better than the DBUTILS-17 approach,
however the concept of it being a count(..) method doesn't work. I
suggest making it a queryForLong that returns a long, though I'm not
sure if turning null into 0 makes sense without the semantics.

Neither of these solutions seem right :)

> DBUTILS-16 ResultSetRowProcessor abstract handler and some classes
> rework There are patches provided. This request for improvement is two
> years old. Henri Yandell posted a comment earlier this year that says
> "FIX or WONTFIX for 1.1."

The patch removes some public API code, so that part is a no-no. I've
reworked the patch and I don't see any reason not to apply it. Any
thoughts before I do? Does anyone think the toBeanList stuff should be

> These seven issues are all that are scheduled against the 1.1 release of
> dbutils. Four other unscheduled issues are not described in this
> message.

Two of the issues (DBUTILS-30 and part of DBUTILS-28) deal with a
variant of the Bean code that loads an existing bean rather than a new
one. I think that would be worth putting in 1.1 - need to compare Kyle
and David's implementations and document nicely concerning David's
threading worries. What do you think?

DBUTILS-29 is good, but someone would need to have the itch. Definitely not 1.1.

DBUTILS-14 is also something that should be looked at beyond 1.1.

Thanks again,


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message