[ 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
