On Tue, Feb 10, 2009 at 2:32 AM, Dan Fabulich <d...@fabulich.com> wrote:
> 1) OptimalBeanListHandler > > http://issues.apache.org/jira/browse/DBUTILS-37 > 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 > http://issues.apache.org/jira/browse/DBUTILS-28 > > 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 > http://issues.apache.org/jira/browse/DBUTILS-34 > > 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. Cheers, -L
