ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Gooch <mrwiz...@k12system.com>
Subject RE: Using Map as a parameter object
Date Mon, 21 Dec 2009 01:32:50 GMT
I think option 3 is probably the best.

Two takes that both work.
http://users.k12system.com/mrwizard/software/ibatis-3beta7-mapfix1.patch
http://users.k12system.com/mrwizard/software/ibatis-3beta7-mapfix2.patch


Thoughts?
Joe
 

> -----Original Message-----
> From: Joe Gooch [mailto:mrwizard@k12system.com] 
> Sent: Sunday, December 20, 2009 1:07 AM
> To: 'user-java@ibatis.apache.org'
> Subject: Using Map as a parameter object
> 
> 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-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
> 
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org


Mime
View raw message