You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dan Fabulich <da...@fabulich.com> on 2009/02/11 12:36:01 UTC
[dbutils] bugfixing/java5 branches ready for merge
I've fixed a bunch of bugs in the bugfixing branch. I think I've fixed
all except bug DBUTILS-30/-28 (they're dupes).
https://svn.apache.org/repos/asf/commons/sandbox/dbutils/bugfixing
http://svn.apache.org/viewvc/commons/sandbox/dbutils/bugfixing/
http://svn.apache.org/viewvc/commons/sandbox/dbutils/bugfixing/?view=log
I've also done a bunch of java5-izing (generics/varargs) in the java5
branch, and merged in the bug fixes from the bugfixing branch.
https://svn.apache.org/repos/asf/commons/sandbox/dbutils/java5
http://svn.apache.org/viewvc/commons/sandbox/dbutils/java5/
The java5 branch is meant to be exactly like the bugfixing branch, except
with generics and varargs. The generics and varargs should be erased at
compile time, so the runtime API should be indistinguishable from the
runtime API of dbutils-1.2.
Review/comments welcome.
If I were a commons/dbutils committer right now, I think I'd probably do
these things (all of which require committer karma):
1) Merge "bugfixing" back to trunk
2) Close out all of the bugs I fixed
3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
4) Make a dbutils/1.x branch
5) Merge "java5" back to trunk
6) Stage/vote on a dbutils-2.0 release based on java5/trunk
... and then start working on crazy API refactorings like my interface
bean idea and Liam's RowHolder suggestions, in preparation for a 3.0
release or something.
However, I am not, in fact, a commons/dbutils committer, so somewhere in
there it might be nice to have a vote about that. ;-)
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbutils] bugfixing/java5 branches ready for merge
Posted by Dan Fabulich <da...@fabulich.com>.
Liam Coughlin wrote:
> DBUTILS-49 QueryRunner - fillStatement method does not work for
> PostgreSQL database drivers<https://issues.apache.org/jira/browse/DBUTILS-49>
> I'm pretty sure this is addressed with the fill change to use the
> parametermetadata.
Yes, this bug is yet another dupe of DBUTILS-44 and friends. I think it's
fixed in 742865... This bug was heavily duplicated, not surprising that I
missed a copy.
> DBUTILS-48 Maintaining a parallel Java 1.5 version of
> DButils<https://issues.apache.org/jira/browse/DBUTILS-49>
> You folks are covering this with the different branch configs post buf fix.
+1, close it.
> DBUTILS-47 Add a StatementFiller to be able to provide a Bean for
> updates, instead of bean
> values.<https://issues.apache.org/jira/browse/DBUTILS-49>
> I'm pretty sure this is outside the scope of dbutils, and would be covered
> by things users of the library add
> to it's extensible framework.
>
> DBUTILS-43 an helper set of classes for JDBC processing with prepared
> statement <https://issues.apache.org/jira/browse/DBUTILS-49>
> This is not trivial -- tackle it now, or tackle it later?
I see DBUTILS-47 and DBUTILS-43 as dupes of DBUTILS-29, fixed in 742870
(and tweaked in later revisions). They all just want to have some way of
using a bean or Object[] to manage a PreparedStatement, IMO.
> DBUTILS-30 [dbutils] New ResultSetHandler -
> ObjectHandler<https://issues.apache.org/jira/browse/DBUTILS-49>
> I'm pretty sure this is outside the scope of dbutils, and would be covered
> by things users of the library add
> to it's extensible framework.
Indeed, I felt the best way to handle this was to use
BeanUtils.copyProperties. We should just close this bug out.
> DBUTILS-28 [dbutils] Stored Procedure Runner and Bean Reuse Handler code
> submission <https://issues.apache.org/jira/browse/DBUTILS-49>
> This is sort of a weird double issue that rolls up DBUTILS-43 and
> DBUTILS-30.
>
> I think you probably want to defer any work with stored procedures for a
> little while because there's just more interesting and important things to
> work on.
DBUTILS-28 is a half-dupe of DBUTILS-30, but stored procedures
(CallableStatement) is its own ball of wax not covered by DBUTILS-43
(which covers only PreparedStatements, a supertype of CallableStatement).
Regardless, I don't think we should include Kyle's patch; we should close
out DBUTILS-28, in favor of DBUTILS-50 which I just filed. DBUTILS-50
should be done someday.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbutils] bugfixing/java5 branches ready for merge
Posted by Liam Coughlin <ls...@gmail.com>.
DBUTILS-49 QueryRunner - fillStatement method does not work for
PostgreSQL database drivers<https://issues.apache.org/jira/browse/DBUTILS-49>
I'm pretty sure this is addressed with the fill change to use the
parametermetadata.
DBUTILS-48 Maintaining a parallel Java 1.5 version of
DButils<https://issues.apache.org/jira/browse/DBUTILS-49>
You folks are covering this with the different branch configs post buf fix.
DBUTILS-47 Add a StatementFiller to be able to provide a Bean for
updates, instead of bean
values.<https://issues.apache.org/jira/browse/DBUTILS-49>
I'm pretty sure this is outside the scope of dbutils, and would be covered
by things users of the library add
to it's extensible framework.
DBUTILS-43 an helper set of classes for JDBC processing with prepared
statement <https://issues.apache.org/jira/browse/DBUTILS-49>
This is not trivial -- tackle it now, or tackle it later?
DBUTILS-30 [dbutils] New ResultSetHandler -
ObjectHandler<https://issues.apache.org/jira/browse/DBUTILS-49>
I'm pretty sure this is outside the scope of dbutils, and would be covered
by things users of the library add
to it's extensible framework.
DBUTILS-28 [dbutils] Stored Procedure Runner and Bean Reuse Handler code
submission <https://issues.apache.org/jira/browse/DBUTILS-49>
This is sort of a weird double issue that rolls up DBUTILS-43 and
DBUTILS-30.
I think you probably want to defer any work with stored procedures for a
little while because there's just more interesting and important things to
work on.
In short -- you should probably just close them or mark them inactive.
On Wed, Feb 25, 2009 at 5:07 AM, Henri Yandell <fl...@gmail.com> wrote:
> On Tue, Feb 24, 2009 at 9:55 AM, Dan Fabulich <da...@fabulich.com> wrote:
> > Henri Yandell wrote:
> >
> >> 742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
> >> RuntimeException throwing needs String arg. Generally not trusting the
> >> Java API here to work beautifully and wanting to have covered a bunch
> >> of use cases.
> >
> > Thanks for reviewing!
> >
> > I tweaked exception handling and added unit tests in bugfixing branch
> > revision 747449. As I wrote the unit tests I manuallly looked at the
> > exception stacktraces and verified that they provided useful error
> messages
> > to the user. http://svn.apache.org/viewvc?view=rev&revision=747449
> >
> > I also merged those changes to java5 branch revision 747452.
> >
> >> So apart from the one commit, I'm +1 on the changes on the bugfixes
> >> branch.
> >
> > In that case, I think we're ready to contemplate executing the plan I'd
> > identified earlier:
> >
> >>> If I were a commons/dbutils committer right now, I think I'd probably
> do
> >>> these things (all of which require committer karma):
> >>>
> >>> 1) Merge "bugfixing" back to trunk
> >>> 2) Close out all of the bugs I fixed
> >>> 3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
> >>> 4) Make a dbutils/1.x branch
> >>> 5) Merge "java5" back to trunk
> >>> 6) Stage/vote on a dbutils-2.0 release based on java5/trunk
> >
> > How do we want to begin work on this? Henri, do you want to these steps?
> > Alternately, I can do them myself if I get the karma to do so...?
>
> I've gone ahead with the merge and bug closing.
>
> Any thoughts on the remaining 6 open issues in JIRA?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [dbutils] bugfixing/java5 branches ready for merge
Posted by Henri Yandell <fl...@gmail.com>.
On Tue, Feb 24, 2009 at 9:55 AM, Dan Fabulich <da...@fabulich.com> wrote:
> Henri Yandell wrote:
>
>> 742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
>> RuntimeException throwing needs String arg. Generally not trusting the
>> Java API here to work beautifully and wanting to have covered a bunch
>> of use cases.
>
> Thanks for reviewing!
>
> I tweaked exception handling and added unit tests in bugfixing branch
> revision 747449. As I wrote the unit tests I manuallly looked at the
> exception stacktraces and verified that they provided useful error messages
> to the user. http://svn.apache.org/viewvc?view=rev&revision=747449
>
> I also merged those changes to java5 branch revision 747452.
>
>> So apart from the one commit, I'm +1 on the changes on the bugfixes
>> branch.
>
> In that case, I think we're ready to contemplate executing the plan I'd
> identified earlier:
>
>>> If I were a commons/dbutils committer right now, I think I'd probably do
>>> these things (all of which require committer karma):
>>>
>>> 1) Merge "bugfixing" back to trunk
>>> 2) Close out all of the bugs I fixed
>>> 3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
>>> 4) Make a dbutils/1.x branch
>>> 5) Merge "java5" back to trunk
>>> 6) Stage/vote on a dbutils-2.0 release based on java5/trunk
>
> How do we want to begin work on this? Henri, do you want to these steps?
> Alternately, I can do them myself if I get the karma to do so...?
I've gone ahead with the merge and bug closing.
Any thoughts on the remaining 6 open issues in JIRA?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbutils] bugfixing/java5 branches ready for merge
Posted by Liam Coughlin <ls...@gmail.com>.
I vote for karma.
On Tue, Feb 24, 2009 at 12:55 PM, Dan Fabulich <da...@fabulich.com> wrote:
> Henri Yandell wrote:
>
> 742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
>> RuntimeException throwing needs String arg. Generally not trusting the
>> Java API here to work beautifully and wanting to have covered a bunch
>> of use cases.
>>
>
> Thanks for reviewing!
>
> I tweaked exception handling and added unit tests in bugfixing branch
> revision 747449. As I wrote the unit tests I manuallly looked at the
> exception stacktraces and verified that they provided useful error messages
> to the user. http://svn.apache.org/viewvc?view=rev&revision=747449
>
> I also merged those changes to java5 branch revision 747452.
>
> So apart from the one commit, I'm +1 on the changes on the bugfixes
>> branch.
>>
>
> In that case, I think we're ready to contemplate executing the plan I'd
> identified earlier:
>
> If I were a commons/dbutils committer right now, I think I'd probably do
>>> these things (all of which require committer karma):
>>>
>>> 1) Merge "bugfixing" back to trunk
>>> 2) Close out all of the bugs I fixed
>>> 3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
>>> 4) Make a dbutils/1.x branch
>>> 5) Merge "java5" back to trunk
>>> 6) Stage/vote on a dbutils-2.0 release based on java5/trunk
>>>
>>
> How do we want to begin work on this? Henri, do you want to these steps?
> Alternately, I can do them myself if I get the karma to do so...?
>
>
> -Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [dbutils] bugfixing/java5 branches ready for merge
Posted by Dan Fabulich <da...@fabulich.com>.
Henri Yandell wrote:
> 742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
> RuntimeException throwing needs String arg. Generally not trusting the
> Java API here to work beautifully and wanting to have covered a bunch
> of use cases.
Thanks for reviewing!
I tweaked exception handling and added unit tests in bugfixing branch
revision 747449. As I wrote the unit tests I manuallly looked at the
exception stacktraces and verified that they provided useful error
messages to the user.
http://svn.apache.org/viewvc?view=rev&revision=747449
I also merged those changes to java5 branch revision 747452.
> So apart from the one commit, I'm +1 on the changes on the bugfixes branch.
In that case, I think we're ready to contemplate executing the plan I'd
identified earlier:
>> If I were a commons/dbutils committer right now, I think I'd probably do
>> these things (all of which require committer karma):
>>
>> 1) Merge "bugfixing" back to trunk
>> 2) Close out all of the bugs I fixed
>> 3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
>> 4) Make a dbutils/1.x branch
>> 5) Merge "java5" back to trunk
>> 6) Stage/vote on a dbutils-2.0 release based on java5/trunk
How do we want to begin work on this? Henri, do you want to these steps?
Alternately, I can do them myself if I get the karma to do so...?
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbutils] bugfixing/java5 branches ready for merge
Posted by Henri Yandell <fl...@gmail.com>.
Looking at the revisions on the bugfixes branch:
742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
RuntimeException throwing needs String arg. Generally not trusting the
Java API here to work beautifully and wanting to have covered a bunch
of use cases.
743293 - +1 - rename GenericListHandler
743292 - +1 - Minor opt
743278 - +1 - Generics preparation
743269 - +1 - Improved CaseInsensitiveMap
743097 - +1 - Optimization. Small risk of API backwards incompat problems.
742865 - +1 - setNull fix
742704 - +1 - Simple API change
742701 - +1 - Regression bug
742696 - +1 - NPE fix
741987 - +1 - Branching trunk
So apart from the one commit, I'm +1 on the changes on the bugfixes branch.
Hen
On Wed, Feb 11, 2009 at 3:36 AM, Dan Fabulich <da...@fabulich.com> wrote:
>
> I've fixed a bunch of bugs in the bugfixing branch. I think I've fixed all
> except bug DBUTILS-30/-28 (they're dupes).
>
> https://svn.apache.org/repos/asf/commons/sandbox/dbutils/bugfixing
> http://svn.apache.org/viewvc/commons/sandbox/dbutils/bugfixing/
> http://svn.apache.org/viewvc/commons/sandbox/dbutils/bugfixing/?view=log
>
> I've also done a bunch of java5-izing (generics/varargs) in the java5
> branch, and merged in the bug fixes from the bugfixing branch.
>
> https://svn.apache.org/repos/asf/commons/sandbox/dbutils/java5
> http://svn.apache.org/viewvc/commons/sandbox/dbutils/java5/
>
> The java5 branch is meant to be exactly like the bugfixing branch, except
> with generics and varargs. The generics and varargs should be erased at
> compile time, so the runtime API should be indistinguishable from the
> runtime API of dbutils-1.2.
>
> Review/comments welcome.
>
> If I were a commons/dbutils committer right now, I think I'd probably do
> these things (all of which require committer karma):
>
> 1) Merge "bugfixing" back to trunk
> 2) Close out all of the bugs I fixed
> 3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
> 4) Make a dbutils/1.x branch
> 5) Merge "java5" back to trunk
> 6) Stage/vote on a dbutils-2.0 release based on java5/trunk
>
> ... and then start working on crazy API refactorings like my interface bean
> idea and Liam's RowHolder suggestions, in preparation for a 3.0 release or
> something.
>
> However, I am not, in fact, a commons/dbutils committer, so somewhere in
> there it might be nice to have a vote about that. ;-)
>
> -Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org