commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kyle Miller...@kylemiller.com>
Subject Re: [dbutils] Buglist Was: need help from a commons committer
Date Mon, 01 Aug 2005 13:19:20 GMT
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 <flamefew@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


Mime
View raw message