[dbutils] Buglist Was: need help from a commons committer

[Henri Yandell <fl...@gmail.com>]

Said I'd do a bit of dbutils tonight, so thought I'd summarise the
bugzilla bugs. Get people's opinions etc.

5 issues in bugzilla currently, which is a pretty small amount.
They're nearly all  enhancement requests of one kind or another, which
is also good.

#33108 - Request to throw unsupported exceptions from MockResultSet,
and I presume MockResultSetData rather than returning null. I don't
see anything obvious to change, so I assume that if this is still
happening then it's a side-effect of dynamic proxying (seems odd, but
been a while since I've used them). Any thoughts?

#27531 - Todo task from David. Using beans for sql statement
parameters, as well as result sets. Had any further ideas on how to do
this David?

#29392 - reworking of ResultSetHandler code to make development
easier. Looks fairly involved to dig into, I'm assuming no one has
yet? Is the complication of genericizing this worth  the development
ease?

#31977 - Request for ExistingBeanResultSetHandler. #33477 has an
implementation of this attached, though it appears to require
simplification.

#33477 - Request for StoredProcedure support. Supporting StoredProcs
seems worthwhile for dbutils, hopefully in such a way that the entire
ResultSetHandler layer can easily be re-used. If I continue to get
pushed into having to support them at work, I might be able to do some
work on this :) From David's comments, looks like the existing
attachment is not in common Java style and needs some
reformatting/cleaning up.

=============

#33108 seems worthwhile, though it's an API change. 
#27531 feels like it would complicate the API too much.
#29392 needs some context I think, though that's probably on the
mailing list somewhere.
#31977 is ugly from an API point of view. Kyle's patch works well
enough for a single row, though I think it shouldn't create new
classes as well, but this concept makes little sense to me if you are
expecting more than one row back. The only reason I could think of for
that would be some optimisation attempt. By using extension, Kyle's
shown that it's easy for a user to do this on their own if they'd
like. Possibly we could show the guts of Kyle's example in the javadoc
for BeanProcesser.
#33477 is worth investigation, but needs some discussion/thought.
This'll be hard to do without those involved having itches, but it
seems to me that anywhere there is a PreparedStatement, we should be
considering a CallableStatement option.

For the last bug, it may be that as a CallableStatement is a subclass
of PreparedStatement, that most of the API would need no changes and
I'm being overly worried to be concerned about the possibility of
stored-proc functionality just being tacked onto the side of dbutils.

All I got atm.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [dbutils] Buglist Was: need help from a commons committer

[Kyle Miller <k...@kylemiller.com>]

I'm currently simplifying the Reuse Handler, and
making the style changes to Stored Procedure code.  I
should be resubmitting patches by the end of the week.

Kyle

--- Henri Yandell <fl...@gmail.com> wrote:

> Said I'd do a bit of dbutils tonight, so thought I'd
> summarise the
> bugzilla bugs. Get people's opinions etc.
> 
> 5 issues in bugzilla currently, which is a pretty
> small amount.
> They're nearly all  enhancement requests of one kind
> or another, which
> is also good.
> 
> #33108 - Request to throw unsupported exceptions
> from MockResultSet,
> and I presume MockResultSetData rather than
> returning null. I don't
> see anything obvious to change, so I assume that if
> this is still
> happening then it's a side-effect of dynamic
> proxying (seems odd, but
> been a while since I've used them). Any thoughts?
> 
> #27531 - Todo task from David. Using beans for sql
> statement
> parameters, as well as result sets. Had any further
> ideas on how to do
> this David?
> 
> #29392 - reworking of ResultSetHandler code to make
> development
> easier. Looks fairly involved to dig into, I'm
> assuming no one has
> yet? Is the complication of genericizing this worth 
> the development
> ease?
> 
> #31977 - Request for ExistingBeanResultSetHandler.
> #33477 has an
> implementation of this attached, though it appears
> to require
> simplification.
> 
> #33477 - Request for StoredProcedure support.
> Supporting StoredProcs
> seems worthwhile for dbutils, hopefully in such a
> way that the entire
> ResultSetHandler layer can easily be re-used. If I
> continue to get
> pushed into having to support them at work, I might
> be able to do some
> work on this :) From David's comments, looks like
> the existing
> attachment is not in common Java style and needs
> some
> reformatting/cleaning up.
> 
> =============
> 
> #33108 seems worthwhile, though it's an API change. 
> #27531 feels like it would complicate the API too
> much.
> #29392 needs some context I think, though that's
> probably on the
> mailing list somewhere.
> #31977 is ugly from an API point of view. Kyle's
> patch works well
> enough for a single row, though I think it shouldn't
> create new
> classes as well, but this concept makes little sense
> to me if you are
> expecting more than one row back. The only reason I
> could think of for
> that would be some optimisation attempt. By using
> extension, Kyle's
> shown that it's easy for a user to do this on their
> own if they'd
> like. Possibly we could show the guts of Kyle's
> example in the javadoc
> for BeanProcesser.
> #33477 is worth investigation, but needs some
> discussion/thought.
> This'll be hard to do without those involved having
> itches, but it
> seems to me that anywhere there is a
> PreparedStatement, we should be
> considering a CallableStatement option.
> 
> For the last bug, it may be that as a
> CallableStatement is a subclass
> of PreparedStatement, that most of the API would
> need no changes and
> I'm being overly worried to be concerned about the
> possibility of
> stored-proc functionality just being tacked onto the
> side of dbutils.
> 
> All I got atm.
> 
> Hen
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org