commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject [dbutils] Buglist Was: need help from a commons committer
Date Mon, 01 Aug 2005 04:52:54 GMT
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


Mime
View raw message