Return-Path: 
 <user-java-return-13519-apmail-ibatis-user-java-archive=ibatis.apache.org@ibatis.apache.org>
Delivered-To: apmail-ibatis-user-java-archive@www.apache.org
Received: (qmail 90381 invoked from network); 23 Jan 2008 20:05:27 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 23 Jan 2008 20:05:27 -0000
Received: (qmail 71126 invoked by uid 500); 23 Jan 2008 20:05:11 -0000
Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org
Received: (qmail 71109 invoked by uid 500); 23 Jan 2008 20:05:11 -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 71098 invoked by uid 99); 23 Jan 2008 20:05:10 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Jan 2008 12:05:10 -0800
X-ASF-Spam-Status: No, hits=-2.0 required=10.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [129.55.12.41] (HELO ll.mit.edu) (129.55.12.41)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Jan 2008 20:04:56 +0000
Received: (from smtp@localhost)
	by ll.mit.edu (8.12.10/8.8.8) id m0NK4msF029842;
	Wed, 23 Jan 2008 15:04:48 -0500 (EST)
Received: from UNKNOWN(              ), claiming to be "[155.34.198.124]"
 via SMTP by llpost, id smtpdAAARnaOJ5; Wed Jan 23 15:04:23 2008
Message-ID: <47979DD6.5010709@ll.mit.edu>
Date: Wed, 23 Jan 2008 15:04:38 -0500
From: Vadim Grinshpun <vadim@ll.mit.edu>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: user-java@ibatis.apache.org
Subject: Re: "can't infer the SQL type" of a bean property whose type is a
 generic parameter.
References: <4790D2A6.7090903@ll.mit.edu> <14980767.post@talk.nabble.com>
In-Reply-To: <14980767.post@talk.nabble.com>
Content-Type: multipart/alternative;
 boundary="------------040603070503010309080901"
X-Virus-Checked: Checked by ClamAV on apache.org

This is a multi-part message in MIME format.
--------------040603070503010309080901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Specifying javaType does seem to work around the problem, and might be 
better than introducing wrapper methods (as I originally did)
However, I'd really like to find out is whether this is a bug in iBATIS 
(in which case I can file a bug report), or if this is expected 
behaviour and/or known limitation  (in which case it would be good to 
document it somewhere, I guess).
I hope someone knowledgeable about iBATIS internals can voice their 
opinion on that...

Thanks,
-Vadim


paulomourajr wrote:
> Hi, Grinshpun,
>
> I faced this same problem a couple of hours ago. In my case, I have a
> generic class like this (names were changed for the sake of
> confidentiality):
>
> public class GenericModel<PK extends Serializable> {
>
>      protected PK id;
>
>     public PK getId(){
>        return id;
>     }
>
>     public void setId(PK value){
>          this.id = value;
>     }
> }
>
> and one class like this:
>
> public UF extends GenericModel<Long> {
>
>     private String name;
>
>     //getters and setters
> }
>
> The original result map and update statement generated using abator were
> like this:
>
>   <resultMap class="UF" id="UFResult">
>     <result column="COD_UF" jdbcType="BIGINT" property="id"/>
>     <result column="NAM_UF" jdbcType="VARCHAR" property="name"/>
>   </resultMap>
>
>   <update id="updateByPrimaryKey" parameterClass="UF">
>     update uf
>     set NAM_UF = #name:VARCHAR#
>     where COD_UF = #id:BIGINT#
>   </update>
>
> When I tried to use them, I got the same problem you reported. One solution
> I found was to specify the java type in each statement using this property.
> Changed result map and update statement are here:
>
>   <resultMap class="UF" id="UFResult">
>     <result column="COD_UF" jdbcType="BIGINT" property="id"
> javaType="long"/>
>     <result column="NAM_UF" jdbcType="VARCHAR" property="name"/>
>   </resultMap>
>
>   <update id="updateByPrimaryKey" parameterClass="UF">
>     update uf
>     set NAM_UF = #name:VARCHAR#
>     where COD_UF = #id,javaType=long,jdbcType
> =BIGINT#
>   </update>
>
> After this, everything went fine. But I found this solution a little
> cumbersome, since it is not a special type which requires a special type
> handler. Anybody has another alternative to this?
>
> Regards.
>
>
> Vadim Grinshpun wrote:
>   
>> Hi all,
>>
>> I just ran into an interesting problem, and I'm curious whether I'm 
>> doing something wrong, or if it's a known limitation or bug in iBATIS 
>> (or its interaction with the JDBC driver?). I'm using iBATIS 2.3.0 with 
>> a PostgreSQL's jdbc driver 8.2-504.
>>
>> Let's say I have the following classes:
>>
>> // wrapper that attaches an attribute to things; a poor-man's mix-in class
>> class Wrapper<T>{
>>     String wrapperAttribute;
>>     T value;
>>     String getAttribute() { return wrapperAttribute;}
>>     T getValue() { return value; };
>>      // remaining bean accessors are defined but not shown
>>      // ...
>> }
>>
>> // a class that uses the  wrapper:
>> class FooBean{
>>    Wrapper<String> wrappedString;
>>    Wrapper<Date> wrappedDate;
>>    Wrapper<SomeEnum> wrappedEnum; // Enum and its TypeHandlerCallback 
>> are defined elsewhere, not shown
>>    // the obvious get/set accessors are defined below, not shown
>>    // ...
>> }
>> // end code
>>
>> FooBean is then passed as a parameter to an insert statement, which 
>> looks, roughly, along the lines of:
>>
>>  <insert ... >
>>       INSERT INTO mytable ( string_field, date_field, enum_field )
>>       VALUES( #wrappedString.value#,
>>                       #wrappedDate.value#,
>>                       #wrappedEnum.value# )
>>  </insert>
>>  
>> When trying to run the code, the #wrappedString.value# part of the 
>> statement works just fine, but for the #wrappedDate.value# I  get an
>> error:
>>     "PSQLException: Can't infer the SQL type to use for an instance of 
>> java.util.Date. Use setObject() with an explicitly Types value to 
>> specify the type to use."
>>
>> Seeing this, I tried adding the jdbc type to the parameter map, as shown:
>>                       #wrappedDate.value:TIMESTAMP#
>> This produced the same exact error.
>>
>> Then I tried adding a wrapper method,"Date getWrappedDateValue" which 
>> simply calls getWrappedDate().getValue(), and thus returns a Date 
>> object, but then I got the same error for the wrappedEnum...
>>
>> Can anyone explain this? Is there a way to get this to work properly? I 
>> first thought that this has to do with Java's generic not preserving 
>> enough information for this to work, but as the error message clearly 
>> shows, the type info is retrievable...
>> Thanks for any insight!
>>
>> -Vadim
>>
>>
>>
>>     
>
>   


--------------040603070503010309080901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Specifying javaType does seem to work around the problem, and might be
better than introducing wrapper methods (as I originally did)<br>
However, I'd really like to find out is whether this is a bug in iBATIS
(in which case I can file a bug report), or if this is expected
behaviour and/or known limitation&nbsp; (in which case it would be good to
document it somewhere, I guess). <br>
I hope someone knowledgeable about iBATIS internals can voice their
opinion on that...<br>
<br>
Thanks,<br>
-Vadim<br>
<br>
<br>
paulomourajr wrote:
<blockquote cite="mid:14980767.post@talk.nabble.com" type="cite">
  <pre wrap="">Hi, Grinshpun,

I faced this same problem a couple of hours ago. In my case, I have a
generic class like this (names were changed for the sake of
confidentiality):

public class GenericModel&lt;PK extends Serializable&gt; {

     protected PK id;

    public PK getId(){
       return id;
    }

    public void setId(PK value){
         this.id = value;
    }
}

and one class like this:

public UF extends GenericModel&lt;Long&gt; {

    private String name;

    //getters and setters
}

The original result map and update statement generated using abator were
like this:

  &lt;resultMap class="UF" id="UFResult"&gt;
    &lt;result column="COD_UF" jdbcType="BIGINT" property="id"/&gt;
    &lt;result column="NAM_UF" jdbcType="VARCHAR" property="name"/&gt;
  &lt;/resultMap&gt;

  &lt;update id="updateByPrimaryKey" parameterClass="UF"&gt;
    update uf
    set NAM_UF = #name:VARCHAR#
    where COD_UF = #id:BIGINT#
  &lt;/update&gt;

When I tried to use them, I got the same problem you reported. One solution
I found was to specify the java type in each statement using this property.
Changed result map and update statement are here:

  &lt;resultMap class="UF" id="UFResult"&gt;
    &lt;result column="COD_UF" jdbcType="BIGINT" property="id"
javaType="long"/&gt;
    &lt;result column="NAM_UF" jdbcType="VARCHAR" property="name"/&gt;
  &lt;/resultMap&gt;

  &lt;update id="updateByPrimaryKey" parameterClass="UF"&gt;
    update uf
    set NAM_UF = #name:VARCHAR#
    where COD_UF = #id,javaType=long,jdbcType
=BIGINT#
  &lt;/update&gt;

After this, everything went fine. But I found this solution a little
cumbersome, since it is not a special type which requires a special type
handler. Anybody has another alternative to this?

Regards.


Vadim Grinshpun wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi all,

I just ran into an interesting problem, and I'm curious whether I'm 
doing something wrong, or if it's a known limitation or bug in iBATIS 
(or its interaction with the JDBC driver?). I'm using iBATIS 2.3.0 with 
a PostgreSQL's jdbc driver 8.2-504.

Let's say I have the following classes:

// wrapper that attaches an attribute to things; a poor-man's mix-in class
class Wrapper&lt;T&gt;{
    String wrapperAttribute;
    T value;
    String getAttribute() { return wrapperAttribute;}
    T getValue() { return value; };
     // remaining bean accessors are defined but not shown
     // ...
}

// a class that uses the  wrapper:
class FooBean{
   Wrapper&lt;String&gt; wrappedString;
   Wrapper&lt;Date&gt; wrappedDate;
   Wrapper&lt;SomeEnum&gt; wrappedEnum; // Enum and its TypeHandlerCallback 
are defined elsewhere, not shown
   // the obvious get/set accessors are defined below, not shown
   // ...
}
// end code

FooBean is then passed as a parameter to an insert statement, which 
looks, roughly, along the lines of:

 &lt;insert ... &gt;
      INSERT INTO mytable ( string_field, date_field, enum_field )
      VALUES( #wrappedString.value#,
                      #wrappedDate.value#,
                      #wrappedEnum.value# )
 &lt;/insert&gt;
 
When trying to run the code, the #wrappedString.value# part of the 
statement works just fine, but for the #wrappedDate.value# I  get an
error:
    "PSQLException: Can't infer the SQL type to use for an instance of 
java.util.Date. Use setObject() with an explicitly Types value to 
specify the type to use."

Seeing this, I tried adding the jdbc type to the parameter map, as shown:
                      #wrappedDate.value:TIMESTAMP#
This produced the same exact error.

Then I tried adding a wrapper method,"Date getWrappedDateValue" which 
simply calls getWrappedDate().getValue(), and thus returns a Date 
object, but then I got the same error for the wrappedEnum...

Can anyone explain this? Is there a way to get this to work properly? I 
first thought that this has to do with Java's generic not preserving 
enough information for this to work, but as the error message clearly 
shows, the type info is retrievable...
Thanks for any insight!

-Vadim



    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>

--------------040603070503010309080901--