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]
