On 11/1/06, Alan Canon <acanon@genscape.com> 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.
Applied.
> 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
deprecated?
> 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,
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|