Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 75045 invoked from network); 15 Feb 2007 13:50:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Feb 2007 13:50:24 -0000 Received: (qmail 34688 invoked by uid 500); 15 Feb 2007 13:50:28 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 34678 invoked by uid 500); 15 Feb 2007 13:50:28 -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 34667 invoked by uid 99); 15 Feb 2007 13:50:28 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Feb 2007 05:50:28 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jchase3@gmail.com designates 64.233.162.228 as permitted sender) Received: from [64.233.162.228] (HELO nz-out-0506.google.com) (64.233.162.228) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Feb 2007 05:50:18 -0800 Received: by nz-out-0506.google.com with SMTP id q3so531078nzb for ; Thu, 15 Feb 2007 05:49:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HXM1IPWjywHRuzbyTiCUVR9d7VzjIfckXAS/NC0/qJbmA0LpL9Cb5Nj9iBNJWNl6pDwSroedDCextHwdNDMSd7/69cYwd2wCC9d5SXSImkf5hO/y3yHoK8Z+pz67FQgWXibL69WWSxdhLY15/BTKcGmCxlc4DwKs/kH0mFoUS70= Received: by 10.114.182.1 with SMTP id e1mr989673waf.1171547396590; Thu, 15 Feb 2007 05:49:56 -0800 (PST) Received: by 10.114.75.4 with HTTP; Thu, 15 Feb 2007 05:49:56 -0800 (PST) Message-ID: <48a3be200702150549p5317c97k6071ee6d5f6d4ace@mail.gmail.com> Date: Thu, 15 Feb 2007 08:49:56 -0500 From: "Jonathan Chase" To: user-java@ibatis.apache.org Subject: Re: problems with mappings In-Reply-To: <2f55db670702141436r4b0e3539sa134a57deaf70209@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_79497_25870428.1171547396303" References: <48a3be200702111930v25285599we1c6cfc875a2b5ee@mail.gmail.com> <48a3be200702121432l5e34706cg725c2ac93670451f@mail.gmail.com> <2f55db670702141436r4b0e3539sa134a57deaf70209@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_79497_25870428.1171547396303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline My mistake - I was under the assumption that column names were optional and would default to the name of the property specified. i.e. I was thinking: was the same as: After I re-read some docs, I realized I had just imagined it:). "column" is a required attribute, according to the docs. The SQLMaps PDF, page 31, states that both the property and column attributes of are not optional. However, my resultmaps currently are NOT using the column attribute and no errors are being thrown (I would think that the resultmap should be seen as invalid at start up). If the docs say that "column" is required, should a configuration error be thrown if column values aren't specified or should the docs be updated? Jon On 2/14/07, Nathan Maves wrote: > > Why are you not specifying the column name or index? > > On 2/12/07, Jonathan Chase wrote: > > > > I kind of figured out the problem and a solution. > > > > I had an abstract class (AbstractEntity) that my entity (Foo) extended. > > A simplified version of the classes looks like: > > > > public abstract class AbstractEntity { > > private Date creationDate; > > // getters/setters > > } > > > > public class Foo extends AbstractEntity { > > private Date sentOn; > > private String a; > > private String b; > > private String c; > > // getters/setters > > } > > > > (I doubt the abstract class had anything to do with the problem, but I > > didn't factor it out to test that so I left it in for completeness.) > > > > And I had the following resultmap defined: > > > > > > > property name="c" /> > > > > > > The above works just fine. > > > > However, once I did the following: > > > > > > * * > > > > > > > > > > I was getting the problem I previously described (property "a" was being > > set with the value of column "b", property "b" would be set with the value > > of column "c", etc.). > > > > So it looks like this stems from using the same result column > > ("creationDate") twice in the result mapping when not specifying column > > names explicitly. > > > > Also note that by explicitly assigning columns in the s worked > > (like ), but wasn't desirable b/c I > > just avoiding the problem for the time being:). > > > > Any ideas on why this is happening? It seems like there's an off by one > > error happening somewhere in the ibatis code. Is ibatis assuming that > > columns from the result set will only be used once? > > > > It'd be nice (if it hasn't already been documented or reported) to > > figure this one out to prevent others from having the same problem. > > > > Jon > > > > > > On 2/11/07, Jonathan Chase wrote: > > > > > > I'm using a result map like the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When I use the above, for some unexplainable reason, the values for > > > "a" and "b" column values in the Foo class instance are off by one from the > > > database. That is, the Java bean's "a" property has the value that b should > > > have. If there were a "c" property as well, "b" would have "c"'s expected > > > value. > > > > > > I can make things work correctly when I specify the columns explicitly > > > like this: > > > > > > > > > > > > > > > > > > What in the world could cause this? > > > > > > I'm using ibatis 2.3 beta, Mysql 5, Java 5. > > > > > > Thanks, > > > > > > Jon > > > > > > > > ------=_Part_79497_25870428.1171547396303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
My mistake - I was under the assumption that column names were optional and would default to the name of the property specified. 
 
i.e. I was thinking:
 
<result property="foo" />
 
was the same as:
 
<result property="foo" column="foo" />
 
After I re-read some docs, I realized I had just imagined it:).  "column" is a required attribute, according to the docs.
 
The SQLMaps PDF, page 31, states that both the property and column attributes of <result> are not optional.  However, my resultmaps currently are NOT using the column attribute and no errors are being thrown (I would think that the resultmap should be seen as invalid at start up).  
 
If the docs say that "column" is required, should a configuration error be thrown if column values aren't specified or should the docs be updated?  
 
Jon 
 

 
On 2/14/07, Nathan Maves <nathan.maves@gmail.com> wrote:
Why are you not specifying the column name or index? 


On 2/12/07, Jonathan Chase <jchase3@gmail.com > wrote:
I kind of figured out the problem and a solution.
 
I had an abstract class (AbstractEntity) that my entity (Foo) extended.  A simplified version of the classes looks like:
 
public abstract class AbstractEntity {
   private Date creationDate;
   // getters/setters
}
 
public class Foo extends AbstractEntity {
   private Date sentOn;
   private String a;
   private String b;
   private String c;
   // getters/setters
}
 
(I doubt the abstract class had anything to do with the problem, but I didn't factor it out to test that so I left it in for completeness.)
 
And I had the following resultmap defined:
<resultMap id="adsf" class="foo">
  <result property name="creationDate" />
  <result property name="a" /> 
  <result property name="b" /> 
  <result property name="c" />
</resultMap>
 
The above works just fine. 
 
However, once I did the following:
<resultMap id="adsf" class="foo">
  <result property name="creationDate" />
  <result property name="sentOn" column="creationDate" />
  <result property name="a" />
  <result property name="b" /> 
  <result property name="c" />
</resultMap>
 
I was getting the problem I previously described (property "a" was being set with the value of column "b", property "b" would be set with the value of column "c", etc.). 
 
So it looks like this stems from using the same result column ("creationDate") twice in the result mapping when not specifying column names explicitly. 
 
Also note that by explicitly assigning columns in the <result>s worked (like <result property name="a" column="a" />), but wasn't desirable b/c I just avoiding the problem for the time being:).
 
Any ideas on why this is happening?  It seems like there's an off by one error happening somewhere in the ibatis code.  Is ibatis assuming that columns from the result set will only be used once? 
 
It'd be nice (if it hasn't already been documented or reported) to figure this one out to prevent others from having the same problem. 
 
Jon

 
On 2/11/07, Jonathan Chase <jchase3@gmail.com > wrote:
I'm using a result map like the following:
 

<resultMap id="fooResultMap" class="my.Foo" extends= "Abstract.abstractResultMap">

<result property="a" />

<result property="b"  />

</resultMap>

When I use the above, for some unexplainable reason, the values for "a" and "b" column values in the Foo class instance are off by one from the database.  That is, the Java bean's "a" property has the value that b should have.  If there were a "c" property as well, "b" would have "c"'s expected value. 

I can make things work correctly when I specify the columns explicitly like this:

<result property="a" column="a" />

<result property="b" column="b"  />

What in the world could cause this?

I'm using ibatis 2.3 beta, Mysql 5, Java 5.

Thanks,

Jon




------=_Part_79497_25870428.1171547396303--