commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liam Coughlin <>
Subject Re: [dbutils] Questions about a few of bugs
Date Tue, 10 Feb 2009 16:57:11 GMT
On Tue, Feb 10, 2009 at 2:32 AM, Dan Fabulich <> wrote:

> 1) OptimalBeanListHandler
> This bug provides a patch that considerably improves the performance of
> BeanListHandler.
> However, Julien correctly points out that:
>> With the change I propose, the BeanListHandler#handleRow(ResultSet) method
>> is never called anymore. So, any subclass of BeanListHandler which would
>> override this method would not work properly anymore.
> Julien's patch creates a separate "OptimalBeanListHandler" ... but that
> really shouldn't be necessary, right?
> We should be able to just replace the existing BLH with this fast one
> without worrying about users who may have extended BLH#handleRow, I'd
> think... At the very least I think nobody should use the old slow one by
> accident.

Ideally, these classes should be split up more.  There shouldn't really be a
BeanListHandler, just a ListHandler which takes a RowHandler on
construction, and then you can just use the appropriate BeanRowHandler or
OptimizedBeanRowHandler or some other custom row handler to map how you like
which would resolve the whole issue.

Yes, this would be a fairly drastic API change -- one that shold be looked
at pretty seriously for java 5 ports of dbutils.

> 2) Inflate existing object
> I'm a little skeptical of the patch for this bug.  Is this issue important?
>  (It has 0 votes and 0 watchers, so I think not.)

Bean reuse handler is a little odd -- but again it comes back to splitting
out a row handler.  The simplest "real"  use case is in mapping database
generated primary keys back into objects for insert statements.

Stored procedure handling is an entirely different issue, and one of the few
places where database specific handlers will probably be needed which is why
it's been avoided so far i think.

> 3) CaseInsensitiveMap
> Two distinct users claim to want CIM to return the keys in their ORIGINAL
> case (i.e. not lowercased).  Why would anyone need this?  I don't get it.
Given the amount of reflection and property referencing that occurs in java
apps these days, i can think of a million reasons why a CIM should return
the keys in original case.  There shouldn't be any particular performance
implication here, just a little bit of extra memory and housekeeping.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message