Hi! I've been kicking around iBatis3 for a bit, and I'm running into an inconsistency I'd like to resolve.
For most of my DB Handling items I use CaseInsensitiveHashMaps. It's less precise, but since our backend DB is case insensitive, it makes sense to follow through w/ the Java. If I pass in a CaseInsensitiveHashMap, iBatis doesn't see it as such. From looking at the source, it appears DynamicContext, when it finds any type of Map, merely does a putAll into its HashMap. (which is case-sensitive) Thus, my parameter object is really never consulted; instead, the values were taken, which means any decorators on that Map are silently discarded. However, if I create a simple class, say MapHolder, with a getMap() method, which returns my CaseInsensitiveHashMap, I have no problems. My guess is because it resolves map to getMap() via bean methods, and returns my original Map object. So the get() method properly finds all mixed case keys. I'm not sure how widespread this type of usage is... But it seems like an oversight to me. As I see it, there are four ways I can fix this... 1) Use my MapHolder everywhere. However, this seems rather unnecessary... I would think a get() call on the map is more efficient than a bean resolution and then a get()... Probably not significantly so. But it makes my code look inelegant and I have to use map.param everywhere to reference things, which would make it harder to transparently supply a bean later. 2) Replace the empty ContextMap (bindings) with the actual passed in Map. This provides other issues, for instance, casting without knowing the original Generics.... Plus, I don't think iBatis should modify my original map, which it would do almost immediately. (By injecting _parameter) 3) Extend the ContextMap definition such that a map can be provided as a delegate... Much the same way Defaults work in the java.util.Properties object. Any call to ContextMap.get would first consult itself. If it finds a value, return it. If it doesn't, then consult the "child" map (if non-null), and return any value found. I'd also have to wrap containsKey and some other items. 4) Provide some way to provide a Map decorator to DynamicContext... Or redefine the Context with one that uses a CaseInsensitiveHashMap natively... So... Certainly some options. Opinions on which way to go? Thanks. Joe --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org