No rush. I just don't want to lose track of them. Clinton On Mon, Sep 7, 2009 at 11:11 AM, <carlosjosep...@gmail.com> wrote:
> 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 > >
