踩坑之路: MyBatis 替換成 MyBatis-Plus

作者：青石路

來源：cnblogs.com/youzhibing/p/18019399

MyBatis 替換成 MyBatis-Plus

背景介紹

一個老項(xiàng)目，數(shù)據(jù)庫用的是 MySQL 5.7.36 ， ORM 框架用的 MyBatis 3.5.0 ， mysql-connector-java 版本是 5.1.26

新來了一個干練的小伙，精力充沛，看著就是一個喜歡折騰的主

他就覺得 MyBatis 使用起來不夠簡單，要寫的代碼還比較多，覺得有必要替換成 MyBatis-Plus

Mybatis-Plus 替換 Mybatis

先準(zhǔn)備一張表 tbl_order ，然后初始化 2 條數(shù)據(jù)

為了簡化演示，我就直接用 Mybatis-Plus 搭建一個示例 demo ，以此來模擬下 "小伙" 替換的過程

只是用 MyBatis-Plus 替換 MyBatis ，其他組件的版本暫不動

Mybatis-Plus 版本就用 "小伙" 引用的版本：3.1.1 ， mysql-connector-java 版本保持不變還是 5.1.26

示例代碼：play_it_safe

此時運(yùn)行 com.qsl.OrderTest#orderListAllTest ，會報(bào)錯，異常信息如下

注意看 Caused by

不支持的轉(zhuǎn)換類型：java.time.LocalDateTime

誰不支持？mysql-connector-java 不支持！

那 mysql-connector-java 哪個版本支持了，答案是：5.1.37

升級mysql-connector-java

將 mysql-connector-java 升級到 5.1.37 ，再執(zhí)行下 com.qsl.OrderTest#orderListAllTest

不再報(bào)異常，查詢結(jié)果也正確

MyBatis-Plus 替換 Mybatis 似乎就完成了

順的讓人有點(diǎn)懷疑

Conversion not supported for type java.time.LocalDateTime

我們再回過頭去看看前面說到的異常：Conversion not supported for type java.time.LocalDateTime

Mybatis-Plus 替換 MyBatis 之前沒這個異常，替換之后就有了這個異常，這不是 Mybatis-Plus 的問題？

如何找這個異常的根因了？

很簡單，直接從異常堆棧入手

點(diǎn)了之后，你會發(fā)現(xiàn)方法很簡單

這么簡單的代碼能有什么問題？

大家注意看圖中左上角 MyBatis 的版本，是 3.5.1，并不是最初的 3.5.0

有小伙伴可能會問了：不是用 MyBatis-Plus 替換了 MyBatis 嗎，怎么還有 Mybatis ？

這個問題問的真的好，我只想給你個大嘴巴子

你看下 MyBatis-Plus 的官方說明

既然基于 Mybatis 3.5.0 沒有拋異常，而基于 3.5.1 拋了異常， LocalDateTimeTypeHandler 在 3.5.1 肯定做了調(diào)整

我們來看下調(diào)整了什么？

看出什么了？

MyBatis 3.5.0 會處理 LocalDateTime 類型的轉(zhuǎn)換（將 java.sql.Timestamp 轉(zhuǎn)換成 java.time.LocalDateTime ）

然而，注意了，然而來了！！!

然而從 MyBatis 3.5.1 開始，不再處理 LocalDateTime （還包括：LocalDate 、 LocalTime ）類型的轉(zhuǎn)換

而是交由 JDBC 組件，也就是 mysql-connector-java 來實(shí)現(xiàn)

而巧的是， mysql-connector-java 5.1.26 不支持類型 LocalDateTime

那它支持哪些類型了？

我們同樣從異常堆棧入手

點(diǎn)了之后，可以看到下圖

往上滑動鼠標(biāo)，就可以看到支持的類型了

確實(shí)沒有 LocalDateTime 、 LocalDate 和 LocalTime

mysql-connector-java 5.1.37 開始支持 LocalDateTime 、 LocalDate 和 LocalTime ，前面已經(jīng)介紹過了，不再過多贅述

總結(jié)下異常根因：MyBatis 3.5.1 開始不再處理 LocalDateTime 、 LocalDate 和 LocalTime 的轉(zhuǎn)換，而 mysql-connector-java 5.1.37 之前都不支持這些類型

弄清楚這個異常的來龍去脈之后，順的是不是又理所當(dāng)然一些了？

暴風(fēng)雨的來臨

版本上線沒 2 天，該來的終究還是來了

我們往表 tbl_order 中插入一條記錄：INSERT INTO tbl_order VALUES (3, 'asdfgh', NULL, '2024-02-21 20:01:31.111', '2024-02-21 20:02:56.764');

再執(zhí)行 com.qsl.OrderTest#orderListAllTest

此刻我就想問 "小伙" ：刺不刺激？

碰到了異常，那就找原因

同樣從異常堆棧入手

看出什么了？

如果 getTimestamp(columnIndex) 得到的是 NULL ，不就 NullPointerException ？嚴(yán)謹(jǐn)性了？

修復(fù)問題要緊，我們先看哪個版本進(jìn)行修復(fù)了？

將 mysql-connector-java 升級到 5.1.42

問題得以修復(fù)

經(jīng)此一役， "小伙" 似乎成長了很多，但眼里的光卻暗淡了不少

mybatis-plus-issues-1114

無意中看到了這個issue-1114，跟我們前面分析的 Conversion not supported for type java.time.LocalDateTime 是不是同一個問題？

只是我們用到的數(shù)據(jù)庫連接池是默認(rèn)的 HikariCP 而非 Druid

結(jié)合druid/issues/3302來看，如果使用 Druid 作為數(shù)據(jù)庫連接池，出現(xiàn)的異常可能跟我們前面分析的確實(shí)不一樣

所以大家需要根據(jù)自己的實(shí)際情況來分析，但針對異常的分析方法是通用的

修了“不該修的Bug”

這是我親身經(jīng)歷的一次事故，到現(xiàn)在都覺得這鍋背的有點(diǎn)冤

背景介紹

文件分為主文件和附屬文件，主文件生成之后再生成附屬文件

附屬文件生成的時候，會校驗(yàn)其依賴的主文件是否都生成了，如果有任意一個主文件未生成，依賴文件不能生成并拋出異常

這個業(yè)務(wù)還是比較簡單吧

但在附屬文件校驗(yàn)的優(yōu)化上，我背上了生產(chǎn)事故

優(yōu)化前的校驗(yàn)

listFileGenerateLog 作用是根據(jù)參數(shù)查詢文件生成記錄，具體實(shí)現(xiàn)不用關(guān)注

這個校驗(yàn)邏輯是什么？只要有任意一個主文件生成，校驗(yàn)就算通過了，與業(yè)務(wù)要求（主文件全部生成，才算校驗(yàn)通過）不匹配呀

這不是妥妥的 Bug ？

優(yōu)化后的校驗(yàn)

碰到 Bug 你能忍？我是忍不了一點(diǎn)，反手就是一個優(yōu)化

這是不是就符合業(yè)務(wù)要求了？

生產(chǎn)異常

中午升級之后，穩(wěn)定運(yùn)行了一段時間，期間文件正常生成，沒出現(xiàn)任何問題

晚上 19 點(diǎn)，有個附屬文件生成失敗，異常提示：依賴的資源[abc_{yyyyMMdd}.txt]未生成

當(dāng)時看到這個異常的第一眼，覺得既熟悉又陌生，熟悉的是這個異常信息的結(jié)構(gòu)，陌生的是 abc_{yyyyMMdd}.txt ，這不是文件名嗎？

正常來講應(yīng)該是 fileId ，是一個自增的正整數(shù)呀，怎么會是文件名了？

腦中瞬間閃過一個念頭：數(shù)據(jù)庫數(shù)據(jù)有問題？

一查嚇一跳，這個附屬文件關(guān)聯(lián)主文件的字段值是：4356,abc_{yyyyMMdd}.txt ，看最終修改時間是：2021-08-21 15:22:12.652

4356 文件的文件名就是 abc_{yyyyMMdd}.txt ，正常來講，這個關(guān)聯(lián)字段的值應(yīng)該是：4356

敢情這個 校驗(yàn)Bug 完美的兼容了這個臟數(shù)據(jù) ，所以幾年了，一直沒出現(xiàn)異常

是不是有這味了？

這可倒好，我把 Bug 修好，還出現(xiàn)問題了，你說我是不是手賤？

經(jīng)此一役，我眼里的光又暗淡了些許

總結(jié)

關(guān)于對組件的升級，或者對舊代碼的調(diào)整，都有可能牽一發(fā)動全身，影響甚大

我的觀點(diǎn)是：能不動就不要動，改好沒績效，改出問題要背鍋，吃力不討好，又不是不能跑

如果到了不得不改的地步了，那就需要全面的測

最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)、等等。獲取方式：點(diǎn)“在看”，關(guān)注公眾號并回復(fù) 666 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*）