Mybatis3.2.0 and mybatis3.3.0 pass parameters abnormally

The project uses SpringMvc3.2.2+Mybatis3.2.0+SQLServer, which often queries data based on a primary key field, usually of Integer type. When writing sql, it usually looks like this:
<mapper namespace="com.back.dao.PersonDao">
<resultMap id="BaseMap" type="com.back.pojo.Person">
		<result column="pid" property="pid" jdbcType="INTEGER" />
		<result column="name" property="name" jdbcType="VARCHAR" />
		<result column="remark" property="remark" jdbcType="VARCHAR" />
</resultMap>

<select id="get" resultMap="BaseMap"parameterType="java.lang.Integer">
      SELECT
      pid
      , name
      , remark
     FROM person
     WHERE pid= #{pid,jdbcType=INTEGER}
</select>
</mapper>

In the above sql, the parameterType we set is Integer, and the pid type of the query condition is also Integer. The service layer defines an abstract public generic get method, which is implemented by subclasses:
public abstract T get(Serializable paramSerializable);

public T get(Serializable id){
    return ((PersonDao) this.dao).get(id);
}

When called as follows:
Person person = (Person )service.get(pid);

Under mybatis3.2.0 version, a String parameter type is defined when calling, as follows
String pid = "123";
Person person = (Person )service.get(pid);

The final query result is also normal, and there is no parameter type conversion error. Later, after upgrading mybatis to 3.3.0, the problem came. When calling the get method, the originally passed string "123" will prompt that the parameter type is wrong. If it is changed to 123 of the incoming shape, there will be no error.
The above list is that the sql parameter of the xml file is pid= #{pid,jdbcType=INTEGER}, the incoming call may be a string; another case is pid= #{pid,jdbcType=VARCHAR}, the incoming call It may be plastic, both of which can be queried normally in mybatis3.2.0, on the contrary, there will be errors in mybatis3.3.0.
Here is a reminder that you should strictly follow the data type when developing, and you will fall into the pit if you are not careful. It is only for reference.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326178050&siteId=291194637