Some params #{object.property} not accessible after 3.4.1

[rumatoest]

This happens when I'm trying to use object property in select query where condition like #{paramName.someProperty}

MyBatis version

version >= 3.4.2

Database vendor and version

Any database

Steps to reproduce

Interface

public IpLicense getByIpProduct(@Param("ip") String ip, @Param("product") Product.Type product);

Where Product.Type - is nested enum in class Product with method public int getId()

In XML

<select id="getByIpProduct" resultMap="license">
        SELECT * FROM license where ip = #{ip} AND product_id = #{product.id}
</select>

Expected result

Should work as in 3.4.1

Actual result

Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #1 with JdbcType null . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #1 with JdbcType null . Try setting a different JdbcType for this parameter or a different configuration property. Cause: java.lang.ClassCastException: my.domain.Product$Type cannot be cast to java.lang.String
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:77)

[harawata]

Hi @rumatoest ,

Thank you for the report, but I couldn't reproduce the problem.
Please create a repro [1] and upload it to your GitHub repo.

[1] Unit test or example project.

[rumatoest]

Hello. This is more complicated bug, it appears only when my custom type handler added to mybatis environment. And it looks like mybatis calls this custom handler (even if it not used in any DAO) and pass there instace of MapperMethod.ParamMap

Bug reproduced here https://github.com/kr3v/1089

[harawata]

Hi @rumatoest ,

Thanks for the repro!
Here is what happens.

You register MapTypeHandler against HashMap globally.
MyBatis internally uses a subclass of HashMap when dealing with multiple parameters.
Because of an enhancement #859 , MapTypeHandler is used when it is not supposed to.

I'll try to look for a clean solution.
If you need a quick workaround, specify MapTypeHandler in typeHandler attribute of <result /> elements instead of registering it globally.

[harawata]

Hi @rumatoest ,

This should be fixed in the latest 3.4.6 SNAPSHOT.
I would appreciate if you could verify the fix before it goes final.

Thank you!

[rumatoest]

Hello. Our test are not failing any more in 3.4.6.Snapshot, but fails in 3.4.5, thus I think that bug was fixed.

[harawata]

@rumatoest Thanks for verifying the fix!

[rumatoest]

I have a simple question.
Why you are not releasing this bugfix?
IMHO patches that fix bugs should be released as fast as possible not once per year or so.

[Vilkaz]

<version.mybatis>3.4.6</version.mybatis>

org.apache.ibatis.type.TypeException: Error setting non null for parameter #2 with JdbcType null . Try setting a different JdbcType for this parameter or a different configuration property. Cause: java.sql.SQLException: Data type mismatch.
	at org.apache.ibatis.type.BaseTypeHandler.setParameter(BaseTypeHandler.java:55) ~[mybatis-3.4.6.jar:3.4.6]

Caused by: java.sql.SQLException: Data type mismatch.
	at com.ibm.as400.access.JDError.createSQLExceptionSubClass(JDError.java:840) ~[jt400-9.5.JAVA8.jar:JTOpen 9.5]

@harawata can you post an example of a workarround ?

I have a request, there are 2 Integers and one of them is failing :/

Bouth are using the same typeHandler which extends the BaseTypeHandler,

Is the fix live ?

[harawata]

Hi @Vilkaz ,

Yes, this was fixed in 3.4.6, so if it occurs with 3.4.6, it must be a different issue.

It seems that your type handler calls one of 'PreparedStatement.setXxx' methods with an incompatible data.
If you still think it's a MyBatis bug, please open a new issue with the details.
We may need the full stack trace at least.