Sorry, I was just waiting for more feedback about the desirability of the prefix and property/field changes and I thought that you've filed a ticket for the other one. I can't create them just right so I'll do it tonight GMT-3 :).
Best regards -- Carlos On Mon, Sep 07, 2009 at 08:28:25AM -0600, Clinton Begin wrote: > Carlos, are you going to create JIRA tickets for your 3 suggestions? (this > prefix one, the property/field order, and the unconstrained mapper methods) > If it isn't in JIRA, it doesn't have a hope of getting done. :-) > > Clinton > > On Wed, Sep 2, 2009 at 9:20 AM, Clinton Begin <clinton.be...@gmail.com>wrote: > > > Your posts are well researched and since they're more like proposals, > > it's probably a good idea to submit a Jira ticket for each of them. > > > > Cheers, > > Clinton > > > > On 2009-09-01, Carlos Pita <carlosjosep...@gmail.com> wrote: > > >> 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 > > > > > > > > > > -- > > Sent from my mobile device > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
