[jira] Closed: (IBATIS-211) Cache should follow structure of hierarchical resultmaps

["Sven Boden (JIRA)" <ib...@incubator.apache.org>]

     [ http://issues.apache.org/jira/browse/IBATIS-211?page=all ]
     
Sven Boden closed IBATIS-211:
-----------------------------

    Resolution: Won't Fix
     Assign To: Sven Boden

Closed as "won't fix" as announced before.

> Cache should follow structure of hierarchical resultmaps
> --------------------------------------------------------
>
>          Key: IBATIS-211
>          URL: http://issues.apache.org/jira/browse/IBATIS-211
>      Project: iBatis for Java
>         Type: Improvement
>   Components: SQL Maps
>  Environment: n/a
>     Reporter: Reuben Firmin
>     Assignee: Sven Boden

>
> Assume 3 sqlMaps, A, B, C.
> A has resultMapA, which contains a mapping to a select query in B, which in turn maps to Cs. In other words, we have:
> B[] A.getBs();
> C[] B.getCs();
> When a cache (cacheA) is implemented at A, the Bs and Cs are also cached in it (cacheA), despite the existence of cacheB and cacheC at their respective levels. This means that flushOnExecute statements must be defined for B and C on cacheA's declaration, *i.e. within A's namespace*. This is error prone, since development on B or C is affected by the cache on A; somebody adding or renaming a mutator on B or C would not necessarily know that they have to add or edit a corresponding flushOnExecute to cacheA. 
> The logic (perhaps optional) should be:
> If resultMapA maps to other sqlMaps, and those sqlMaps have their own caches, then *defer to those caches to cache those objects*.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira