[ http://issues.apache.org/jira/browse/IBATIS-211?page=comments#action_12371006 ]
Sven Boden commented on IBATIS-211: ----------------------------------- The request for caching to follow the structure of ResultMaps is not valid as iBATIS does not use object identity: the results are cached, not the seperate objects. So e.g. if 2 queries would return the "same" object you would find the object twice in the cache. What I could possible envision is a kind of "flushOnFlush" statement which cascade cache flushes whenever a cache is flushed (taking care of cyclic dependencies, ...). It would be relatively easy to implement but currently I don't see a real need for it. So similar as IBATIS-222 I would like to close this JIRA around March, 24th > 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 > > 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
