> If I'm right, both alternatives are easily implementable: giving prefix > at use-place or giving it at definition-place. I tend to prefer the > first one.
Sorry, I confused use-place with mappedStatement. Actually, the use-place in Iawo's proposal was a nested resultMap. There is no "global" prefix in the sense I understood it. The previous analysis needs to be corrected. Just to be sure I'm being clear, a couple of examples of what I understand by use-place and definition-place follows: use-place (Iawo's): <association property="prop" resultMap="map" prefix="p_"/> definition-place (mine): <resultMap id="map" extends="map2" prefix="p_"/> Let's assume a field DefaultResultSetHandler.currentPrefix that is initialized to "". For the definition-place variant we need a property resultMap.prefix also. resultMap.prefix (if not null) will be concatenated to currentPrefix at the beginning of loadResultObject execution and removed upon exit. This recursively extends the prefix as needed. For the use-place variant we need a property resultMapping.prefix instead (which only makes sense for nested non-inlined associations and collections). In this case, the concatenation/removal must occur before/after calling loadResultObject from processNestedJoinResults. Notice that the outer resultMap can't be prefixed this way (except that prefix is also allowed as a property of mappedStatement), but that doesn't seem like a big loss. In both cases currentPrefix will be prefixed to resultMapping.getColumn() in the course of getPrimitiveResultMappingValue execution as suggested before. Still pretty simple. Sorry again for the confusion, I'm both overexerted and overexcited, I need some rest. Best regards -- Carlos --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
