Return-Path: 
 <user-java-return-17739-apmail-ibatis-user-java-archive=ibatis.apache.org@ibatis.apache.org>
Delivered-To: apmail-ibatis-user-java-archive@www.apache.org
Received: (qmail 42251 invoked from network); 10 Sep 2009 21:21:09 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 10 Sep 2009 21:21:09 -0000
Received: (qmail 50970 invoked by uid 500); 10 Sep 2009 21:21:08 -0000
Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org
Received: (qmail 50915 invoked by uid 500); 10 Sep 2009 21:21:08 -0000
Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-java-help@ibatis.apache.org>
List-Unsubscribe: <mailto:user-java-unsubscribe@ibatis.apache.org>
List-Post: <mailto:user-java@ibatis.apache.org>
List-Id: <user-java.ibatis.apache.org>
Reply-To: user-java@ibatis.apache.org
Delivered-To: mailing list user-java@ibatis.apache.org
Received: (qmail 50907 invoked by uid 99); 10 Sep 2009 21:21:08 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Sep 2009 21:21:08 +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 guyr-ml1@burntmail.com
 designates 70.87.63.122 as permitted sender)
Received: from [70.87.63.122] (HELO mx02.burntmail.com) (70.87.63.122)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Sep 2009 21:20:58 +0000
Received: from pool-71-246-200-220.washdc.fios.verizon.net ([71.246.200.220]
 helo=[127.0.0.1])
	by mx02.burntmail.com with esmtpa (Exim 4.63)
	(envelope-from <guyr-ml1@burntmail.com>)
	id 1Mlr4F-0000TO-KR
	for user-java@ibatis.apache.org; Thu, 10 Sep 2009 16:20:35 -0500
Message-ID: <4AA96DA3.9060004@burntmail.com>
Date: Thu, 10 Sep 2009 17:20:35 -0400
From: Guy Rouillier <guyr-ml1@burntmail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: user-java@ibatis.apache.org
Subject: Re: Reusing @Results annotation
References: <4AA91F56.90705@burntmail.com>
 <16178eb10909101142x1a70cce0w3f6bf55e6f88c02c@mail.gmail.com>
In-Reply-To: <16178eb10909101142x1a70cce0w3f6bf55e6f88c02c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 090910-0, 09/10/2009), Outbound message
X-Antivirus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

Clinton Begin wrote:
> I put a lot of thought into that... I landed on this position:  Java 
> Annotations suck, and aren't very good at much.  The very little that 
> they are good for are simple things.  Therefore, I tried to keep the 
> annotations limited in scope and targeted only simple problems. 

Clinton, thank you very much for the quick reply and for the 
suggestions.  Fortunately, I've never had to implement annotations 
myself, just use them.  As you suggest, they don't appear to be up to 
the task of defining a ResultMap independent of the method to which it 
is attached.  That's too bad; would have been nice to be able to move 
pieces of the SqlMap between XML and annotations and have them all work 
together.

The direction I'm leaning is to standardize on keeping ResultMaps and 
the selects that use them in XML, but allow other DML (inserts, updates, 
and selects returning a single value like count) to be placed into 
annotations.

I like annotations because the SQL is adjacent to the method that uses 
it.  Our company and software development team are small, so we write 
our own SQL.  I work within Eclipse; is there any way I can link a 
source method to the corresponding SQL definition in the XML mapper 
file, such that I can double-click on a method, like my selectBundle 
example, and have Eclipse open up the correct XML mapper file with the 
cursor on the selectBundle <select> tag?

Thanks.

> 
> If you have advanced needs, I suggest sticking with the XML.  
> 
> And on a per mapper/namespace level, I suggest using either XML or 
> annotations, and not both.
> 
> Cheers,
> Clinton
> 
> On Thu, Sep 10, 2009 at 9:46 AM, Guy Rouillier <guyr-ml1@burntmail.com 
> <mailto:guyr-ml1@burntmail.com>> wrote:
> 
>     I'm new to iBatis, starting out with version 3.  One common usage
>     scenario we have is to run different queries that all return the
>     same result type, sliced and diced different ways.  Using XML, this
>     is easy to achieve as I can have all selects refer to the same
>     ResultMap.  I can't figure out how to implement a similar approach
>     using @Results annotation.
> 
>     Here is my first example using annotations:
> 
>     public interface BundleMapper
>       {
>       @Select(value="select * from bundle where bundle_id = #{id}")
>       @Results(value=
>          {
>           @Result(column="cust_id", property="custId"),
>           @Result(column="status_dt", property="statusDt")
>           })
>       Bundle selectBundle(String id);
>       }
> 
>     My Bundle class contains about 30-40 fields, but I just wanted to
>     save some typing so I just created two.  This approach seems to
>     require me to define @Results for each select.  So if I had another
>     method that also returned Bundle, I'd have to define the 40-line
>     @Results annotation again.
> 
>     Using annotations, is there any way to define an @Results mapping
>     one time and then refer to it multiple times from different methods?
> 
>     Also, I think it would be handy to merge XML definitions and
>     annotation definitions into a single application-wide namespace, so
>     that I could refer to XML definitions from annotations.  That would
>     address the issue I'm discussing here.  I could define a ResultMap
>     in XML, then refer to it as needed from annotations.
> 
>     Thanks.
> 
>     -- 
>     Guy Rouillier
> 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>     <mailto:user-java-unsubscribe@ibatis.apache.org>
>     For additional commands, e-mail: user-java-help@ibatis.apache.org
>     <mailto:user-java-help@ibatis.apache.org>
> 
> 


-- 
Guy Rouillier

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org