Liam Coughlin wrote:
On Tue, Feb 10, 2009 at 2:32 AM, Dan Fabulich <d...@fabulich.com> wrote:
1) OptimalBeanListHandler
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.
Ah, but the whole point of this enhancement is that it's unperformant to
use RowProcessor#toBean on each row; it's much faster to call
RowProcessor#toBeanList once. So there's no such thing as an
OptimizedBeanRowHandler; the optimization is to not use a RowHandler!
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.
Well, here's my thinking:
1) We don't provide a public CaseInsensitiveMap in our API. The CIM is a
purely private object used in the guts of BasicRowProcessor.
This is why I don't understand the point of the bug... Why would anyone
care how this internal object is implemented, so long as BasicRowProcessor
works?
2) Extra housekeeping = slower performance
3) The biggest risk here is accidentally introducing thread-safety
problems. The patch applied to DBUTILS-34 is not thread-safe (I think?)
because it keeps two internal data structures (the "real" map and the
"lowerCaseMap") that can fall out-of-sync, corrupting the map.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
