ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Grinshpun <va...@ll.mit.edu>
Subject Re: "can't infer the SQL type" of a bean property whose type is a generic parameter.
Date Wed, 23 Jan 2008 20:04:38 GMT
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
>>
>>
>>
>>     
>
>   


Mime
View raw message