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
>
>
>
--
View this message in context:
http://www.nabble.com/%22can%27t-infer-the-SQL-type%22-of-a-bean-property-whose-type-is-a-generic-parameter.-tp14956735p14980767.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
