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 <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
