mybatis plus框架@TableField註解不生效問題及解決方案
mybatis-plus手寫sql的時候@TableField註解不生效的問題剖析和解決方案
一、問題描述
最近遇到一個mybatis plus的問題，@TableField註解不生效，導致查出來的字段反序列化後為空
數據庫表結構：
CREATE TABLE `client_role` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主鍵', `name` varchar(64) NOT NULL COMMENT '角色的唯一標識', `desc` varchar(64) DEFAULT NULL COMMENT '角色描述', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='角色表'
對應的實體類
@Data
@EqualsAndHashCode(callSuper = false)
@Accessors(chain = true)
@TableName("client_role")
@ApiModel(value = "ClientRole對象", description = "角色表")
public class ClientRole implements Serializable {
private static final long serialVersionUID = 1L;
/**
* 自增主鍵
*/
@ApiModelProperty(value = "自增主鍵")
@TableId(value = "id", type = IdType.AUTO)
private Long id;
* 角色的唯一標識
@NotEmpty
@ApiModelProperty(value = "角色的唯一標識")
@TableField("name")
private String name;
* 角色描述
@ApiModelProperty(value = "角色描述")
@TableField("`desc`")
private String description;
}
就是description字段為空的問題，查詢sql如下
<select id="selectOneByName" resultType="com.kdyzm.demo.springboot.entity.ClientRole">
select *
from client_role
where name = #{name};
</select>
然而，如果不手寫sql，使用mybatis plus自帶的LambdaQuery查詢，則description字段就有值瞭。
ClientRole admin = iClientRoleMapper.selectOne(
new LambdaQueryWrapper<ClientRole>().eq(ClientRole::getName, "admin")
);
真是活見鬼，兩種方法理論上結果應該是一模一樣的，最終卻發現@TableField字段在手寫sql這種方式下失效瞭。
二、解決方案
定義ResultMap，在xml文件中定義如下
<resultMap type="com.kdyzm.demo.springboot.entity.ClientRole" id="ClientRoleResult">
<result property="id" column="id"/>
<result property="name" column="name"/>
<result property="description" column="desc"/>
</resultMap>
<select id="selectOneByName" resultMap="ClientRoleResult">
select *
from client_role
where name = #{name};
</select>
select標簽中resultType改成resultMap，值為resultMap標簽的id，這樣description字段就有值瞭。
問題很容易解決，但是有個問題需要問下為什麼：為什麼@TableField註解在手寫sql的時候就失效瞭呢？
三、關於@TableField註解失效原因的思考
當數據庫字段和自定義的實體類中字段名不一致的時候，可以使用@TableField註解實現矯正，以上面的代碼為例，
ClientRole admin = iClientRoleMapper.selectOne(
new LambdaQueryWrapper<ClientRole>().eq(ClientRole::getName, "admin")
);
這段代碼被翻譯成sql，它被翻譯成這樣
好傢夥，原來@TableField註解功能是通過加別名實現的。
那如果是手寫sql的話，它如何把別名加上去呢？答案就是沒辦法加上去，因為手寫sql太靈活瞭，不在mybatis plus功能框架內，那是屬於原生mybatis的功能范疇，不支持也就正常瞭。
四、Mapper接口LambdaQuery方法調用過程梳理
進一步探討，@TableField註解是如何生成別名的呢，那就要研究下源碼瞭。
1、Mapper接口調用實際上使用的是動態代理技術
mybatis定義的都是一堆的接口，並沒有實現類，但是卻能正常調用，這很明顯使用瞭動態代理技術，實際上註入spring的時候接口被包裝成瞭代理對象，這就為debug源碼提供瞭突破口。
可以看到，這個代理對象實際的類名為com.baomidou.mybatisplus.core.override.MybatisMapperProxy,它實現瞭InvocationHandler接口，確定是JDK動態代理無疑瞭，那麼所有的邏輯都會走com.baomidou.mybatisplus.core.override.MybatisMapperProxy#invoke方法
2、mybatis plus對查詢的單獨處理
根據上面一步找到源碼的入口，一步一步走下去，接口調用到瞭com.baomidou.mybatisplus.core.override.MybatisMapperMethod#execute方法
public Object execute(SqlSession sqlSession, Object[] args) {
Object result;
switch (command.getType()) {
case INSERT: {
Object param = method.convertArgsToSqlCommandParam(args);
result = rowCountResult(sqlSession.insert(command.getName(), param));
break;
}
case UPDATE: {
Object param = method.convertArgsToSqlCommandParam(args);
result = rowCountResult(sqlSession.update(command.getName(), param));
break;
}
case DELETE: {
Object param = method.convertArgsToSqlCommandParam(args);
result = rowCountResult(sqlSession.delete(command.getName(), param));
break;
}
case SELECT:
if (method.returnsVoid() && method.hasResultHandler()) {
executeWithResultHandler(sqlSession, args);
result = null;
} else if (method.returnsMany()) {
result = executeForMany(sqlSession, args);
} else if (method.returnsMap()) {
result = executeForMap(sqlSession, args);
} else if (method.returnsCursor()) {
result = executeForCursor(sqlSession, args);
} else {
// TODO 這裡下面改瞭
if (IPage.class.isAssignableFrom(method.getReturnType())) {
result = executeForIPage(sqlSession, args);
// TODO 這裡上面改瞭
} else {
Object param = method.convertArgsToSqlCommandParam(args);
result = sqlSession.selectOne(command.getName(), param);
if (method.returnsOptional()
&& (result == null || !method.getReturnType().equals(result.getClass()))) {
result = Optional.ofNullable(result);
}
}
}
break;
case FLUSH:
result = sqlSession.flushStatements();
break;
default:
throw new BindingException("Unknown execution method for: " + command.getName());
}
if (result == null && method.getReturnType().isPrimitive() && !method.returnsVoid()) {
throw new BindingException("Mapper method '" + command.getName()
+ " attempted to return null from a method with a primitive return type (" + method.getReturnType() + ").");
}
return result;
}
這段代碼特點在於它對於非查詢類型的請求（比如插入、更新和刪除），都直接委托給瞭sqlSeesion的相應的方法調用，而對於查詢請求，則邏輯比較復雜，畢竟sql最復雜的地方就是查詢瞭；還有另外一個特點，針對不同的返回結果類型，也走不同的邏輯；由於我這裡查詢返回的是一個實體對象，所以最終走到瞭如下斷點
從代碼上來看，也隻是委托給瞭SqlSessionTemplate對象處理瞭，然而SqlSessionTemplate的全包名是org.mybatis.spring.SqlSessionTemplate，它是mybatis集成spring的官方功能，和mybatis plus沒關系，就這如何能讓@TableField註解發揮作用呢？
3、findOne實際上還是要查詢List
繼續debug幾次，到瞭一個有趣的方法org.apache.ibatis.session.defaults.DefaultSqlSession#selectOne(java.lang.String, java.lang.Object)
原來單獨查詢一個對象，還是要查詢List，然後取出第一個對象返回；如果查詢出多個對象，則直接拋出TooManyResultsException，建表的時候不做唯一索引查出來多個對象的時候拋出的異常就是在這裡做的。
有意思的是，方法執行到這裡，傳參隻有兩個，一個是方法名，另外一個是查詢參數
總之還是要繼續查看selectList的邏輯，才能搞清楚邏輯
4、mybatis接口上下文信息MappedStatement
上一步說到selectList方法調用隻傳遞瞭兩個參數，一個是方法名，一個是方法參數，隻是這兩個參數是無法滿足查詢的請求的，畢竟最重要的sql語句都沒傳，debug下去，到瞭一處比較重要的地方，就解開瞭我的疑問：org.apache.ibatis.session.defaults.DefaultSqlSession#selectList(java.lang.String, java.lang.Object, org.apache.ibatis.session.RowBounds)
在這個方法裡，根據statement也就是方法名獲取到瞭MappedStatement對象，這個對象裡存儲著這個關於本次查詢需要的上下文信息，繼續debug，來到一個方法com.baomidou.mybatisplus.core.executor.MybatisCachingExecutor#query(org.apache.ibatis.mapping.MappedStatement, java.lang.Object, org.apache.ibatis.session.RowBounds, org.apache.ibatis.session.ResultHandler)
它調用瞭MappedStatement對象的getBoundSql方法，便得到瞭帶有別名的sql字符串，也就是說，這個getBoundSql方法形成瞭這段sql字符串，debug進去看看
5、mybatis plus別名自動設置的邏輯
debug ms.getBoundSql方法，最終到瞭方法：org.apache.ibatis.scripting.xmltags.MixedSqlNode#apply，該方法入參是org.apache.ibatis.scripting.xmltags.DynamicContext類型，其內部維護瞭一個java.util.StringJoiner對象，專門用於拼接sql
contents對象是個List類表，其有八個元素，經過八個元素的apply方法調用之後，DynamicContext的sqlBuilder對象就有瞭值瞭
原來別名是在這裡設置的；這裡先暫且不談，查詢流程還沒結束，先看整個的流程。
6、mybatis plus的sql日志打印
我們看到的sql日志是如何打印出來的？上一步已經獲取到瞭sql，接下來繼續debug，就會看到sql打印的代碼：org.apache.ibatis.logging.jdbc.ConnectionLogger#invoke
7、最終查詢的執行
我們知道，無論是mybatis還是其它框架，最終執行查詢都要遵循java api規范，上一步已經獲取到瞭PreparedStatement，最終在這個方法執行瞭查詢
org.apache.ibatis.executor.statement.PreparedStatementHandler#query
8、結果集處理
查詢完之後要封裝結果集，封裝邏輯的起始方法：org.apache.ibatis.executor.resultset.DefaultResultSetHandler#handleResultSets
可以看到，這段邏輯就是在從Satement對象中循環取數據，然後調用org.apache.ibatis.executor.resultset.DefaultResultSetHandler#handleResultSet方法處理每一條數據
9、每一條數據的單獨處理
繼續debug，可以看到對每一條結果數據的單獨處理的邏輯：org.apache.ibatis.executor.resultset.DefaultResultSetHandler#getRowValue(org.apache.ibatis.executor.resultset.ResultSetWrapper, org.apache.ibatis.mapping.ResultMap, java.lang.String)
這裡首先使用自動字段名映射的方式填充返回值，然後使用resultMap繼續填充返回值，最後返回rowValue作為最終反序列化完成的值。
至此，整個查詢過程基本上就結束瞭。
五、@TableField註解生效原理
1、別名sql在mapper方法執行前就已經確定
上一步在梳理Mapper接口調用過程的時候在第5點說過，DynamicContext內部維護瞭一個StringJoiner對象用於拼接sql，在經過MixedSqlNode內部的8個SqlNode處理之後，StringJoiner就有瞭完整的sql語句。我們知道@TableField生效的原理是設置別名，那麼別名是這時候設置上去的嗎？
SqlNode有很多實現類，目測mybatis通過實現SqlNode接口實現對XML語法的支持。裡面最簡單的SqlNode就是StaticTextSqlNode瞭
可以看到這個類內部維護瞭一個text字符串，然後將這個text字符串掛到DynamicContext的StringJoiner，就是這麼簡單的邏輯，然而別名sql就是在這裡設置上去的：
答案已經一目瞭然瞭，代碼在執行到這裡的時候，這個StaticTextSqlNode裡面的text就已經準備好瞭sql瞭，等到它執行apply方法的時候直接就給掛到瞭DynamicConetxt的StringJoiner，這說明瞭別名sql的設置在Mapper方法執行之前就已經確定瞭，而非是代碼執行過程中動態的解析。
2、@TableField註解的外層解析
@TableFied註解何時被解析？可以推測肯定是mybatis plus starter搞的鬼，但是入口方法調用鏈很長，找到解析點會比較困難，最直接的方法就是在借助intelij工具，右鍵註解，findUseage，自然就找到瞭這個解析方法：com.baomidou.mybatisplus.core.metadata.TableInfoHelper#initTableFields。在該方法上打上斷點，debug模式啟動服務，就找到瞭調用鏈
可以看到，一切的起點就在com.baomidou.mybatisplus.autoconfigure.MybatisPlusAutoConfiguration配置類，在方法com.baomidou.mybatisplus.autoconfigure.MybatisPlusAutoConfiguration#sqlSessionFactory中創建SqlSessionFactory時開啟整個的解析流程，整個流程非常復雜，最終會調用到com.baomidou.mybatisplus.core.injector.AbstractSqlInjector#inspectInject方法，在執行完成com.baomidou.mybatisplus.core.metadata.TableInfoHelper#initTableInfo方法之後，TableInfo對象中的fiedList就已經存儲瞭數據庫字段和實體字段的映射關系：
initTableInfo方法內部解析瞭@TableField註解，並且生成瞭數據庫字段和實體字段的映射關系，並最終保存到瞭TableInfo對象。
然而，這個實體對象無法直接使用，因為在前面Mapper接口調用梳理的過程中就知道瞭，在拼接sql的時候別名已經以sql的形式存儲在瞭StaticTextSqlNode，還要繼續debug尋找轉換點
3、MappedStatement對象創建和保存
緊接著要執行的代碼在循環註入自定義方法這塊，上一步解析好的TableInfo會被應用到以下十七種內置方法，這和我們常用的com.baomidou.mybatisplus.core.mapper.BaseMapper接口中的方法數量是相同的，當然也就不包括手寫sql的那個自定義方法。
在循環體上打上斷點，看看這個inject方法做瞭什麼事情，由於我們隻關心com.baomidou.mybatisplus.core.injector.methods.SelectOne，所以直接進入SelectOne的inject方法打上斷點
好傢夥，這個sqlSource可太眼熟瞭，基本上可以確定這個和上面分析的5、mybatis plus別名自動設置的邏輯中的DynamicSqlSource是同一個對象，如果將其放到MappedStatement對象內，那就和Mapper接口方法執行的流程對的上瞭，從接下來執行的方法addSelectMappedStatementForTable名字上來看，做的也正是這個事情，繼續debug，最終到瞭方法org.apache.ibatis.builder.MapperBuilderAssistant#addMappedStatement
該方法創建瞭MappedStatement對象，並且存儲到瞭全局Configuration對象。這樣，在執行Mapper接口方法的時候，根據上面梳理的執行流程中的4、mybatis接口上下文信息MappedStatement，就可以在configuration對象中取出MappedStatement對象用於查詢瞭，這樣，就整個串通瞭@TableFied註解的作用過程。
4、一些疑問
上面梳理瞭LambdaQuery接口執行的過程以及確定瞭@TableField註解在這個過程中是通過給字段起別名的方式實現瞭數據庫字段和實體字段的映射。其實還有幾處疑問需要解決
1、為啥手寫sql@TableField註解就失效瞭呢？雖然在三、關於@TableField註解失效原因的思考中大體上明白瞭失效的合理性，但是從技術層面上來講隻是搞明白瞭內置方法對@TableFied註解的支持，還沒搞明白手寫sql為啥不支持@TableFied註解。再具體點，手寫sql肯定是沒有別名的，那它的DynamicSqlSource和內置方法的DynamicSqlSource有何不同？手寫sql需要定義ResultMap，ResultMap在何時生效的？退一步說，手寫sql和內置方法的查詢是否走的同一個查詢流程呢？
2、使用LambdaQuery的內置方法通過下面的代碼生成MappedStatement對象並且保存到Configuration全局配置中，手寫的sql並不在這個列表中，手寫sql的接口方法何時創建的MappedStatement對象的呢？
六、Mapper接口手寫sql方法調用過程梳理
整個流程基本上和四、Mapper接口LambdaQuery方法調用過程梳理一樣，這裡隻是說下不同之處
1、生成sql的方式不同
在LambdaQuery中，生成sql的方式是使用DynamicSqlSource
其內部維護瞭一個rootSqlNode用於解析sql語句，其中查詢列包含別名被放到瞭一個StaticTextSqlNode中；
但是在手寫sql的時候，不再是DynamicSqlSource，而是RawSqlSource：
內部不再維護MixedSqlNode,而是直接使使用一個sql字符串，該字符串正是xml文件中手寫的sql：
<select id="selectOneByName" resultMap="ClientRoleResult">
select *
from client_role
where name = #{name};
</select>
很明顯，這裡確實是原生的sql，沒有任何的mybatis標簽混雜在裡面。
假如我稍微改一下這段sql又如何？改成如下形式
<select id="selectOneByName" resultMap="ClientRoleResult">
select *
from client_role
<where>
name = #{name};
</where>
</select>
兩段代碼邏輯上是完全一樣的，再次運行debug到此處
可以看到，sqlSource已經變成瞭DynamicSqlSource，隻是它相對於LambdaQuery的查詢方式，少瞭很多個SqlNode節點。雖然變成瞭DynamicSqlSource，但是可以看到還是沒有設置別名，StaticTextSqlNode中存儲瞭xml文件中寫的原始的sql字符串。
這樣可以得出結論：如果xml文件中寫的sql沒有使用任何mybatis的標簽，則會使用RawSqlSource，如果使用瞭例如<where></where>等標簽，則會使用DynamicSqlSource；同樣使用的都是DynamicSqlSource的情況下，手寫Sql的DynamicSqlSource查詢列不會自動增加別名，查詢列取決於手寫sql的代碼。
需要註意的是執行這段代碼的是org.apache.ibatis.mapping.MappedStatement對象，它是在服務啟動的時候創建並保存到全局MybatisConfiguration中的，也就是說，在服務啟動的時候就已經決定瞭在這裡查詢的時候使用的是DynamicSqlSource還是RawSqlSource。
2、結果集處理方式不同
之前說過，即使是查詢一個元素，底層還是會查詢List，然後對每個元素單獨反序列化封裝成實體類對象，這個操作在org.apache.ibatis.executor.resultset.DefaultResultSetHandler#getRowValue(org.apache.ibatis.executor.resultset.ResultSetWrapper, org.apache.ibatis.mapping.ResultMap, java.lang.String)方法中。
需要註意的是402行的applyAutomaticMappings方法執行以及404行的applyPropertyMappings方法執行
當使用LambdaQuery查詢的時候，402行代碼返回的foundValues值為true，方法執行完成，rowValue就有值瞭，見下圖：
404行的applyPropertyMappings方法執行則會直接跳過執行，因為不滿足執行條件；
而當手寫sql方法調用時，402行的applyAutomaticMappings方法執行會返回false，執行完成之後rowValue字段屬性並沒有填充，見下圖：
而404行的applyPropertyMappings方法滿足瞭執行條件，執行完成之後foundValues的值變成瞭true，而rawValue也有值瞭。
為啥呢？
applyAutomaticMappings方法和applyPropertyMappings方法兩個方法從方法名字上來看似乎是對立的兩個方法如果未指定PropertieyMapping，則走applyAutomacitMapping，如果指定瞭則走applyPropertyMapping，但是會不會同時存在兩個方法都走一遍呢？那是肯定的，因為applyPropertyMapping並沒有放在else塊中，它是強制執行的，為瞭驗證這個問題，修改下Xml文件中定義的ResultMap，原來ResultMap長這樣子
<resultMap type="com.kdyzm.demo.springboot.entity.ClientRole" id="ClientRoleResult">
<result property="id" column="id"/>
<result property="name" column="name"/>
<result property="description" column="desc"/>
</resultMap>
現在我改成這個樣子
<resultMap type="com.kdyzm.demo.springboot.entity.ClientRole" id="ClientRoleResult">
<result property="description" column="desc"/>
</resultMap>
刪掉表字段和實體字段同名的映射關系，隻留下不同的映射關系，再次執行手寫sql的接口查詢。
執行完成applyAutomaticMappings方法之後，未在ResultMap中指定映射關系的id和name兩個屬性填充上瞭值，如下圖：
執行完成applyPropertyMappings方法之後，在ResultMap中定瞭映射關系的description字段填充上瞭值，如下圖：
說明瞭一個問題：隻要在ResultMap中沒定義映射關系，就會被applyAutomaticMappings方法處理屬性填充；如果在ResultMap中定義瞭映射關系，則會被applyPropertyMappings方法處理屬性填充；另外，說明瞭ResultMap不需要全部都寫上關系映射，隻需要寫數據庫字段名和實體類字段不一致的映射即可。
那麼如何區分出來哪些字段該走applyAutomaticMappings方法屬性填充，哪些字段該走applyPropertyMappings屬性填充呢？
答案就在傳過來的resultMap對象中，它有個屬性叫ResultMapping，存儲著解析XML文件中ResultMap的映射，如下圖所示：
凡是在resultMapping中的屬性，都走applyPropertyMappings方法，否則走applyAutomaticMappings方法。
3、手寫sql接口方法@TableFied註解失效的原因
一開始未在xml文件中定義ResultMapping，且使用的是手寫sql。根據上面的源碼分析，在未定義ResultMap的情況下，所有的屬性填充都會走org.apache.ibatis.executor.resultset.DefaultResultSetHandler#applyAutomaticMappings方法，其邏輯也比較清晰
首先查找出所有未在xml文件中定義的ResultMap映射表字段集合對這些表字段進行處理，比如如果開啟瞭mapUnderscoreToCamelCase，則會將表字段從下換線變成駝峰命名嘗試從實體類中尋找轉換好的字段，如果找到瞭，則全部放到List<UnMappedColumnAutoMapping> autoMapping從mapping尋找適合的typeHandler解析屬性值，比如Long類型的值會調用LongTypeHandler進行屬性值解析屬性值填充到rawValue
套用上述流程，看看description字段為啥沒填充上去：
- 首先查找出所有未在xml文件中定義的ResultMap映射表字段集合，找到瞭id,name,desc三個表字段
- 對這些表字段進行處理，比如如果開啟瞭mapUnderscoreToCamelCase，則會將表字段從下換線變成駝峰命名，三個字段都無變化
- 嘗試從實體類尋找轉換好的字段，如果找到瞭，則全部放到
List<UnMappedColumnAutoMapping> autoMapping，實體類有三個字段id,name,description，id，name都找到瞭，由於desc和description長得不一樣，所以就沒填充到List<UnMappedColumnAutoMapping> autoMapping，最終上圖中隻有id和name兩個屬性值被add到瞭autoMapping。從mapping尋找適合的typeHandler解析 - 屬性值，這裡隻解析瞭id和name兩個字段的屬性值屬性值填充到rawValue，這裡隻填充瞭id和name兩個字段的屬性值
總結下，desc字段因為沒有在ResultMap中定義，所以不會被applyPropertyMappings方法處理；本來應該被applyAutomaticMappings處理的，又因為和description實體類字段名長得不一樣，就被applyAutomaticMappings方法忽略瞭，成瞭一個兩不管的狀態，所以最終隻能是默認值填充，那就是null瞭。
那麼@TableFied字段真的一點用就沒瞭嗎，上述流程中代碼中怎麼知道數據庫表字段的呢？
表字段都被封裝到瞭ResultSetWrapper對象中，如下圖所示
這些表字段是從執行結果ResultSet中的元數據獲取到的，最終通過構造方法填充屬性值，如下圖所示
所以，當手寫sql的時候，@TableField註解就真的完全沒用瞭。
下面說下手寫sqlmapper方法創建對應MappedStatement對象的過程。
4、手寫SQL的MappedStatement對象的創建
同樣的，手寫sql的MappedStatement對象的創建也是在SqlSessionFactoryBean對象創建的過程中創建的。但是手寫SQL的MappedStatement對象創建的時間遠比mybatis plus內置方法的創建早的多。
創建SqlSessionFactoryBean的入口方法：com.baomidou.mybatisplus.extension.spring.MybatisSqlSessionFactoryBean#buildSqlSessionFactory
這段代碼會解析所有的xml文件並且最終在org.apache.ibatis.builder.MapperBuilderAssistant#addMappedStatement方法中創建手寫sql的MapperStatement並保存到Configuration上下文中。
七、手寫SQL如何讓@TableFiled生效
如果，我就是想手寫SQL，還不想寫ResultMap而且還想@TableField註解生效，又該怎麼做呢？
先說下結論：理論上可行，實踐很困難。下面逐一分析各種方法的可行性。
1、方法一：新增ResultMapping
通過上面的源碼分析，知道瞭mybatis針對每個Mapper接口都創建瞭一個MappedStatement對象，該對象實際上存儲瞭該接口的上下文信息，無論是執行的sql還是結果類型、字段Mapping等都在裡面（不包含ResultSet返回的行動態AutoMapping），在反序列化之前修改該對象，根據@TableFied註解新增數據庫字段和實體類字段的映射關系，就應該能影響反序列化結果。
然而，我發現所有相關的屬性都被修飾成瞭不可修改的集合，這裡有個最關鍵的resultMappings集合，也被修飾成瞭不可修改的集合，看起來官方並不想我們動他們的數據，畢竟萬一出瞭問題，就很難排查是誰導致的瞭。
所以說，這種方式行不通。
2、方法二：使用插件填充未被設置值的屬性
如果沒設置ResultMap，會使用自動映射的方式填充實體類對象，desc和descriptin字段的映射則會失敗，最終到實體類對象裡descriptin字段就為空。若是基於此結果，再做處理，將為空的值嘗試使用@TableFiled註解做映射再次填充，理論上也是可行的，所以我使用mybatis插件的方式重新處理瞭結果：
import com.baomidou.mybatisplus.annotation.TableField;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.apache.ibatis.executor.resultset.DefaultResultSetHandler;
import org.apache.ibatis.executor.resultset.ResultSetHandler;
import org.apache.ibatis.executor.resultset.ResultSetWrapper;
import org.apache.ibatis.mapping.MappedStatement;
import org.apache.ibatis.mapping.ResultMap;
import org.apache.ibatis.plugin.*;
import org.apache.ibatis.session.Configuration;
import org.apache.ibatis.type.JdbcType;
import org.apache.ibatis.type.TypeHandler;
import org.springframework.util.CollectionUtils;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.*;
/**
* @author kdyzm
* @date 2022/1/24
*/
@Slf4j
@Intercepts({
@Signature(
type = ResultSetHandler.class,
method = "handleResultSets",
args = {Statement.class}
)
})
public class ResultSetHandlerPlugin implements Interceptor {
private final Map<String, List<UnMappedColumnMapping>> unMappedColumnMappingCache = new HashMap<>();
private ResultSetWrapper getFirstResultSet(Statement stmt, Configuration configuration) throws SQLException {
ResultSet rs = stmt.getResultSet();
while (rs == null) {
// move forward to get the first resultset in case the driver
// doesn't return the resultset as the first result (HSQLDB 2.1)
if (stmt.getMoreResults()) {
rs = stmt.getResultSet();
} else {
if (stmt.getUpdateCount() == -1) {
// no more results. Must be no resultset
break;
}
}
}
return rs != null ? new ResultSetWrapper(rs, configuration) : null;
}
@Override
public Object intercept(Invocation invocation) throws Throwable {
//通過StatementHandler獲取執行的sql
DefaultResultSetHandler statementHandler = (DefaultResultSetHandler) invocation.getTarget();
MappedStatement mappedStatement = getMappedStatement(statementHandler);
Configuration configuration = mappedStatement.getConfiguration();
Object[] args = invocation.getArgs();
Method method = invocation.getMethod();
Statement statement = (Statement) invocation.getArgs()[0];
ResultSetWrapper firstResultSet = getFirstResultSet(statement, configuration);
List result = (List) invocation.proceed();
//獲得結果集
ResultMap resultMap = mappedStatement.getResultMaps().get(0);
List<UnMappedColumnMapping> unMappedColumnMappings = getUnMappedColumnMapping(firstResultSet, resultMap);
//TODO
return result;
private List<UnMappedColumnMapping> getUnMappedColumnMapping(ResultSetWrapper firstResultSet, ResultMap resultMap) {
Class clazz = resultMap.getType();
List<UnMappedColumnMapping> unMappedColumnMappings = this.unMappedColumnMappingCache.get(clazz.getName());
if (!CollectionUtils.isEmpty(unMappedColumnMappings)) {
return unMappedColumnMappings;
unMappedColumnMappings = new ArrayList<>();
Set<String> mappedProperties = resultMap.getMappedProperties();
Field[] fields = clazz.getDeclaredFields();
for (Field field : fields) {
if (Modifier.isFinal(field.getModifiers())
|| Modifier.isStatic(field.getModifiers())
|| Modifier.isVolatile(field.getModifiers())
) {
continue;
String fieldName = field.getName();
boolean contains = mappedProperties.contains(fieldName);
if (contains) {
TableField annotation = field.getAnnotation(TableField.class);
if (Objects.isNull(annotation)) {
String columnName = annotation.value();
TypeHandler<?> typeHandler = firstResultSet.getTypeHandler(field.getType(), columnName);
if (Objects.isNull(typeHandler)) {
log.error("不支持的字段反序列化：{}", columnName);
log.info("字段={}使用的反序列化工具為：{}", columnName, typeHandler);
UnMappedColumnMapping unMappedColumnMapping = new UnMappedColumnMapping(
columnName,
field.getName(),
typeHandler
);
unMappedColumnMappings.add(unMappedColumnMapping);
this.unMappedColumnMappingCache.put(clazz.getName(), unMappedColumnMappings);
return unMappedColumnMappings;
private MappedStatement getMappedStatement(DefaultResultSetHandler statementHandler) throws NoSuchFieldException, IllegalAccessException {
Field field = statementHandler.getClass().getDeclaredField("mappedStatement");
field.setAccessible(true);
MappedStatement mappedStatement = (MappedStatement) field.get(statementHandler);
return mappedStatement;
public Object plugin(Object target) {
return Plugin.wrap(target, this);
@Data
@AllArgsConstructor
static class UnMappedColumnMapping {
private String columnName;
private String propertyName;
private TypeHandler<?> typeHandler;
}
代碼寫到上述TODO的地方就寫不下去瞭。。。原因是Satement對象中的結果隻能讀一次，在第一次List result = (List) invocation.proceed();執行過後，再次取結果就取不出來瞭。
而且coding的過程中發現其它的問題：MappedStatement對象作為DefaultResultSetHandler的成員變量並沒有暴露GET/SET方法，要想獲取到必須通過反射暴力獲取：
private MappedStatement getMappedStatement(DefaultResultSetHandler statementHandler) throws NoSuchFieldException, IllegalAccessException {
Field field = statementHandler.getClass().getDeclaredField("mappedStatement");
field.setAccessible(true);
MappedStatement mappedStatement = (MappedStatement) field.get(statementHandler);
return mappedStatement;
}
在我感覺其實很不爽，畢竟強扭的瓜不甜。。。
總而言之，這種方式也以失敗告終，那隻能用最後一種終極方法瞭：自定義反序列化的過程。
3、方法三：自定義反序列化過程
這種方式確實可以實現，但是實現起來會很困難，因為不想破壞mybatis和mybaits plus原有的功能，比如：autoMapping、下劃線轉駝峰、resultMap、各種返回類型處理。。。如果自己重新實現，代價就太大瞭，這是得不償失的做法。如果不破壞這些功能，隻是稍微做些修改的話是可以接受的。
4、方法四：增強反序列化過程
首先制定一個反序列化的規則：當手寫sql的時候，自動mapping和resultmap優先級最高，之後若是有未匹配的屬性，則使用@TableField註解嘗試解決，最終如果還是無法匹配，則直接pass掉不做處理。
這裡處理的核心方法就是在mybatis反序列化處理完單個對象之後額外添加邏輯，核心方法就在：DefaultResultSetHandler#getRowValue(org.apache.ibatis.executor.resultset.ResultSetWrapper, org.apache.ibatis.mapping.ResultMap, java.lang.String)方法中
問題就在於此處代碼無法應用動態代理或者切面技術，最終，我使用瞭javassit技術動態修改字節碼對象解決瞭該問題，javassit簡介可以參考文章：使用javassist運行時動態修改字節碼對象
項目源代碼地址：狂盜一枝梅 / mybatis-plus-fix
最終，實現效果上來看，確實解決瞭@TableFiled註解在手寫sql的情況下失效的問題，但是由於額外執行瞭一段代碼，所以執行效率會稍微低一些；而且由於使用瞭javassit，代碼的可讀性和可維護性較低，尤其是在debug代碼的時候會出現靈異現象。。。綜上，作為實驗性的問題解決，雖然能解決問題，但是不建議使用，哈哈
到此這篇關於mybatis plus框架的@TableField註解不生效問題總結的文章就介紹到這瞭,更多相關mybatis plus @TableField註解不生效內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！
推薦閱讀：
- Java面試題沖刺第九天–MyBatis2
- Mybatis-plus常見的坑@TableField不生效問題
- Mybatis結果集映射與生命周期詳細介紹
- Mybatis之@ResultMap,@Results,@Result註解的使用
- Mybatis自關聯查詢一對多查詢的實現示例