Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 68071 invoked from network); 1 Sep 2009 06:51:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Sep 2009 06:51:21 -0000 Received: (qmail 48371 invoked by uid 500); 1 Sep 2009 06:51:20 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 48341 invoked by uid 500); 1 Sep 2009 06:51:20 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 48333 invoked by uid 99); 1 Sep 2009 06:51:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 06:51:20 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of carlosjosepita@gmail.com designates 209.85.221.182 as permitted sender) Received: from [209.85.221.182] (HELO mail-qy0-f182.google.com) (209.85.221.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 06:51:11 +0000 Received: by qyk12 with SMTP id 12so3198845qyk.6 for ; Mon, 31 Aug 2009 23:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=S1an7dtzjgsQ4cCsOoqmS+ToZQ9VHTW6v3+10zdEXXA=; b=Rz8E88WHK65WIANPFGHKmvh1RHcZKlX/1I0AxUkFhVJPE/Rh/8hZS1nwCzWCRUhHQt A9Da/0UWMFZaJjABJg0CAAy56V5F2mCUF8QjfVS3V48zBPdaZ89SNZmFoL755789sw2L Wg7THxXGojBSCVku2oPc5+El9I1ouXjKTy/JI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=pi8SHgt8IC5rFKGUJU46XxGrxH1cN5SKQPrFvi5PpY1nH84JPFxjzh32lDf6fGh6PA 1lIKQqEz3P93LVbKH+yC+OD0MY6mkUcMZEs8Kon+NW6XVBb/VDuTA+7dnB96SvAImxIw JiTxRigjQ7qyACNZT9z9X9vN8kPIr7fulb/fg= MIME-Version: 1.0 Received: by 10.229.39.69 with SMTP id f5mr1834886qce.107.1251787850427; Mon, 31 Aug 2009 23:50:50 -0700 (PDT) In-Reply-To: <7798eaa0908312236y145d64c5p2f518ef0666a6106@mail.gmail.com> References: <7798eaa0908312236y145d64c5p2f518ef0666a6106@mail.gmail.com> Date: Tue, 1 Sep 2009 03:50:50 -0300 Message-ID: <7798eaa0908312350n41e47326s4cbe84e0e6e5e629@mail.gmail.com> Subject: Re: Handling multiple table aliases in a query using one resultMap. From: Carlos Pita To: user-java@ibatis.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org After a closer examination at the implementation of DefaultResultSetHandler even the original proposal by Iwao doesn't look that hard to get working. The sequence of execution is as follows: handleResultSets(mappedStatement) handleResults loadResultObject <-------------------------+ mapResults | processResult | processNestedSelectResult | processSimpleResult | processNestedJoinResults ---------------+ Both processSimpleResult and processNestedJoinResults directly or indirectly call the utility getPrimitiveResultMappingValue, which ultimately calls the typeHandler passing it the column given by the resultMapping. So say prefix is a property of mappedStatement, which is "global" to the entire process, it's just a matter of prefixing it to resultMapping.getColumn() at getPrimitiveResultMappingValue. Both top-level mappings and nested ones (inlined or external) will be affected by this prefix, as desired. Please correct me if I'm wrong, I'm not familiar with ibatis code. 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. Best regards -- Carlos On Tue, Sep 1, 2009 at 2:36 AM, Carlos Pita wrote= : > Hi all, > > I would like to revive this old thread, which is representative of a few > other ones that can be found in the list with some effort. I understand > both the original proposal and the difficulty that Jeff pointed out. > But I think a very simple solution can be implemented if instead of > "parameterizing" the resultmap passing it a prefix at the point of use, > a facility is provided to duplicate a resultmap with a different > prefix using the original one as a template at the point of definition. > Maybe this can be regarded as a kind of extension to the resultmap: > > withPrefix=3D"somePrefix_"/> > > This is handy and I think that it brings no complex implementation > issues along. > > I could work on a patch to support this feature, but I would like to hear > you opinion first. > > Best regards > -- > Carlos > > > > >> Jeff Butler >> Mon, 04 Dec 2006 09:44:51 -0800 >> >> I understand the issue, and your proposed solution. =A0I think the >> implementation could get complex - especially if the referenced result m= ap >> referenced other result maps. =A0Result processing is already pretty com= plex >> in iBATIS - this would add to that complexity. >> >> I'd like to hear from other users to see if this is a big need. =A0My fe= eling >> is that this use case - where you populate different nested objects of t= he >> same type from a single query - is pretty rare. >> >> Jeff Butler >> >> >> >> On 12/4/06, Iwao AVE! <[EMAIL PROTECTED]> wrote: >> >> =A0 =A0 Hi all, >> >> =A0 =A0 It was a great news that [#IBATIS-225] had been implemented. >> =A0 =A0 I'm wondering if it can be improved a little bit more. >> >> =A0 =A0 -- >> =A0 =A0 Assuming I have 2 simple java classes. >> =A0 =A0 Needless to say, there are corresponding tables in a database. >> >> =A0 =A0 public class Staff { >> =A0 =A0 =A0 =A0Integer id; >> =A0 =A0 =A0 =A0String name; >> =A0 =A0 =A0 =A0// ... accessor methods >> =A0 =A0 } >> >> =A0 =A0 public class Section { >> =A0 =A0 =A0 =A0Integer sectionId; >> =A0 =A0 =A0 =A0Staff manager; >> =A0 =A0 =A0 =A0Staff submanager; >> =A0 =A0 =A0 =A0// ... accessor methods >> =A0 =A0 } >> >> =A0 =A0 To retrieve section with its manager and submanager, I will have= a query >> =A0 =A0 like below. >> >> =A0 =A0 >> >> =A0 =A0 Then I will define the sectionResult resultMap. >> =A0 =A0 Currently, it may have to be like this, I suppose. >> >> =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 >> >> =A0 =A0 Because both manager and submanager are instances of Staff, woul= dn't it >> =A0 =A0 be nice to have a way to map these properties using externaly de= fined >> =A0 =A0 resultMap? (In my understanding, I can specify resultMap for one= of >> =A0 =A0 manager or submanager, but not for both of them, right?) >> >> =A0 =A0 So, here's my proposal which introduces 'columnPrefix' attribute= . >> =A0 =A0 On applying staffResult, iBATIS appends the prefix to the name o= f each >> =A0 =A0 column. >> >> =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0columnPrefix=3D"manager_"/> >> =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0columnPrefix=3D"submanager_"/> >> =A0 =A0 >> >> =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 >> >> =A0 =A0 -- >> =A0 =A0 If some of you like it, I will submit new improvement request to= JIRA. >> =A0 =A0 Or, if iBATIS already has a way to achieve this, please show me = how to >> =A0 =A0 do it. >> >> =A0 =A0 -- >> =A0 =A0 Regards, >> >> =A0 =A0 Iwao >> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org For additional commands, e-mail: user-java-help@ibatis.apache.org