01MyBatis 替换成 MyBatis-Plus背景介绍一个老项目数据库用的是 MySQL 5.7.36 ORM 框架用的 MyBatis 3.5.0 mysql-connector-java 版本是 5.1.26新来了一个干练的小伙精力充沛看着就是一个喜欢折腾的主他就觉得 MyBatis 使用起来不够简单要写的代码还比较多觉得有必要替换成 MyBatis-PlusMybatis-Plus 替换 Mybatis先准备一张表 tbl_order 然后初始化 2 条数据为了简化演示我就直接用 Mybatis-Plus 搭建一个示例 demo 以此来模拟下 小伙 替换的过程只是用 MyBatis-Plus 替换 MyBatis 其他组件的版本暂不动Mybatis-Plus 版本就用 小伙 引用的版本 3.1.1 mysql-connector-java 版本保持不变还是 5.1.26示例代码playitsafe此时运行 com.qsl.OrderTest#orderListAllTest 会报错异常信息如下注意看 Caused by不支持的转换类型 java.time.LocalDateTime谁不支持 mysql-connector-java 不支持那 mysql-connector-java 哪个版本支持了答案是 5.1.37升级mysql-connector-java将 mysql-connector-java 升级到 5.1.37 再执行下 com.qsl.OrderTest#orderListAllTest不再报异常查询结果也正确MyBatis-Plus 替换 Mybatis 似乎就完成了顺的让人有点怀疑Conversion not supported for type java.time.LocalDateTime我们再回过头去看看前面说到的异常 Conversion not supported for type java.time.LocalDateTimeMybatis-Plus 替换 MyBatis 之前没这个异常替换之后就有了这个异常这不是 Mybatis-Plus 的问题如何找这个异常的根因了很简单直接从异常堆栈入手点了之后你会发现方法很简单这么简单的代码能有什么问题大家注意看图中左上角 MyBatis 的版本是 3.5.1并不是最初的 3.5.0有小伙伴可能会问了不是用 MyBatis-Plus 替换了 MyBatis 吗怎么还有 Mybatis 这个问题问的真的好我只想给你个大嘴巴子你看下 MyBatis-Plus 的官方说明既然基于 Mybatis 3.5.0 没有抛异常而基于 3.5.1 抛了异常 LocalDateTimeTypeHandler 在 3.5.1 肯定做了调整我们来看下调整了什么看出什么了MyBatis 3.5.0 会处理 LocalDateTime 类型的转换将 java.sql.Timestamp 转换成 java.time.LocalDateTime 然而注意了然而来了!然而从 MyBatis 3.5.1 开始不再处理 LocalDateTime 还包括 LocalDate 、 LocalTime 类型的转换而是交由 JDBC 组件也就是 mysql-connector-java 来实现而巧的是 mysql-connector-java 5.1.26 不支持类型 LocalDateTime那它支持哪些类型了我们同样从异常堆栈入手点了之后可以看到下图往上滑动鼠标就可以看到支持的类型了确实没有 LocalDateTime 、 LocalDate 和 LocalTimemysql-connector-java 5.1.37 开始支持 LocalDateTime 、 LocalDate 和 LocalTime 前面已经介绍过了不再过多赘述总结下异常根因 MyBatis 3.5.1 开始不再处理 LocalDateTime 、 LocalDate 和 LocalTime 的转换而 mysql-connector-java 5.1.37 之前都不支持这些类型弄清楚这个异常的来龙去脉之后顺的是不是又理所当然一些了暴风雨的来临版本上线没 2 天该来的终究还是来了我们往表 tbl_order 中插入一条记录 INSERT INTOtbl_orderVALUES (3, asdfgh, NULL, 2024-02-21 20:01:31.111, 2024-02-21 20:02:56.764);再执行 com.qsl.OrderTest#orderListAllTest此刻我就想问 小伙 刺不刺激碰到了异常那就找原因同样从异常堆栈入手如果 getTimestamp(columnIndex) 得到的是 NULL 不就 NullPointerException 严谨性了修复问题要紧我们先看哪个版本进行修复了将 mysql-connector-java 升级到 5.1.42问题得以修复经此一役 小伙 似乎成长了很多但眼里的光却暗淡了不少mybatis-plus-issues-1114无意中看到了这个issue-1114跟我们前面分析的 Conversion not supported for type java.time.LocalDateTime 是不是同一个问题只是我们用到的数据库连接池是默认的 HikariCP 而非 Druid结合druid/issues/3302来看如果使用 Druid 作为数据库连接池出现的异常可能跟我们前面分析的确实不一样所以大家需要根据自己的实际情况来分析但针对异常的分析方法是通用的02修了“不该修的Bug”这是我亲身经历的一次事故到现在都觉得这锅背的有点冤文件分为主文件和附属文件主文件生成之后再生成附属文件附属文件生成的时候会校验其依赖的主文件是否都生成了如果有任意一个主文件未生成依赖文件不能生成并抛出异常这个业务还是比较简单吧但在附属文件校验的优化上我背上了生产事故优化前的校验listFileGenerateLog 作用是根据参数查询文件生成记录具体实现不用关注这个校验逻辑是什么只要有任意一个主文件生成校验就算通过了与业务要求主文件全部生成才算校验通过不匹配呀这不是妥妥的 Bug 优化后的校验碰到 Bug 你能忍我是忍不了一点反手就是一个优化这是不是就符合业务要求了生产异常中午升级之后稳定运行了一段时间期间文件正常生成没出现任何问题晚上 19 点有个附属文件生成失败异常提示 依赖的资源[abc_{yyyyMMdd}.txt]未生成当时看到这个异常的第一眼觉得既熟悉又陌生熟悉的是这个异常信息的结构陌生的是 abc_{yyyyMMdd}.txt 这不是文件名吗正常来讲应该是 fileId 是一个自增的正整数呀怎么会是文件名了脑中瞬间闪过一个念头数据库数据有问题一查吓一跳这个附属文件关联主文件的字段值是 4356,abc_{yyyyMMdd}.txt 看最终修改时间是 2021-08-21 15:22:12.6524356 文件的文件名就是 abc_{yyyyMMdd}.txt 正常来讲这个关联字段的值应该是 4356敢情这个 校验Bug 完美的兼容了这个脏数据 所以几年了一直没出现异常是不是有这味了这可倒好我把 Bug 修好还出现问题了你说我是不是手贱经此一役我眼里的光又暗淡了些许03总结关于对组件的升级或者对旧代码的调整都有可能牵一发动全身影响甚大我的观点是能不动就不要动改好没绩效改出问题要背锅吃力不讨好又不是不能跑如果到了不得不改的地步了那就需要全面的测试