 mall学习教程官网：macrozheng.com 作者：青石路来源：cnblogs.com/youzhibing/p/18019399 MyBatis 替换成 MyBatis-Plus背景介绍一个老项目，数据库用的是 MySQL 5.7.36 ， ORM 框架用的 MyBatis 3.5.0 ， mysql-connector-java 版本是 5.1.26 新来了一个干练的小伙，精力充沛，看着就是一个喜欢折腾的主  他就觉得 MyBatis 使用起来不够简单，要写的代码还比较多，觉得有必要替换成 MyBatis-Plus Mybatis-Plus 替换 Mybatis先准备一张表 tbl_order ，然后初始化 2 条数据 
为了简化演示，我就直接用 Mybatis-Plus 搭建一个示例 demo ，以此来模拟下 "小伙" 替换的过程 只是用 MyBatis-Plus 替换 MyBatis ，其他组件的版本暂不动 Mybatis-Plus 版本就用 "小伙" 引用的版本：3.1.1 ， mysql-connector-java 版本保持不变还是 5.1.26 示例代码：play_it_safe 此时运行 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.LocalDateTime Mybatis-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 和 LocalTime mysql-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 INTO tbl_order VALUES (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 作为数据库连接池，出现的异常可能跟我们前面分析的确实不一样 所以大家需要根据自己的实际情况来分析，但针对异常的分析方法是通用的 修了“不该修的Bug”这是我亲身经历的一次事故，到现在都觉得这锅背的有点冤  背景介绍文件分为主文件和附属文件，主文件生成之后再生成附属文件 附属文件生成的时候，会校验其依赖的主文件是否都生成了，如果有任意一个主文件未生成，依赖文件不能生成并抛出异常 这个业务还是比较简单吧 但在附属文件校验的优化上，我背上了生产事故 优化前的校验 listFileGenerateLog 作用是根据参数查询文件生成记录，具体实现不用关注 这个校验逻辑是什么？只要有任意一个主文件生成，校验就算通过了，与业务要求（主文件全部生成，才算校验通过）不匹配呀 这不是妥妥的 Bug ？  优化后的校验碰到 Bug 你能忍？我是忍不了一点，反手就是一个优化  这是不是就符合业务要求了？ 生产异常中午升级之后，稳定运行了一段时间，期间文件正常生成，没出现任何问题 晚上 19 点，有个附属文件生成失败，异常提示：依赖的资源[abc_{yyyyMMdd}.txt]未生成 当时看到这个异常的第一眼，觉得既熟悉又陌生，熟悉的是这个异常信息的结构，陌生的是 abc_{yyyyMMdd}.txt ，这不是文件名吗？ 正常来讲应该是 fileId ，是一个自增的正整数呀，怎么会是文件名了？ 脑中瞬间闪过一个念头：数据库数据有问题？ 一查吓一跳，这个附属文件关联主文件的字段值是：4356,abc_{yyyyMMdd}.txt ，看最终修改时间是：2021-08-21 15:22:12.652 4356 文件的文件名就是 abc_{yyyyMMdd}.txt ，正常来讲，这个关联字段的值应该是：4356 敢情这个 校验Bug 完美的兼容了这个脏数据 ，所以几年了，一直没出现异常  是不是有这味了？ 这可倒好，我把 Bug 修好，还出现问题了，你说我是不是手贱？ 经此一役，我眼里的光又暗淡了些许 总结关于对组件的升级，或者对旧代码的调整，都有可能牵一发动全身，影响甚大 我的观点是：能不动就不要动，改好没绩效，改出问题要背锅，吃力不讨好，又不是不能跑 如果到了不得不改的地步了，那就需要全面的测试 Github上 标星60K的电商实战项目mall，全套 视频教程（2023最新版） 已更新完毕！全套教程约40小时，共113期，通过这套教程你可以拥有一个涵盖主流Java技术栈的完整项目经验，同时提高自己独立开发一个项目的能力，下面是项目的整体架构图，感兴趣的小伙伴可以点击链接 mall视频教程 加入学习。 整套 视频教程 的内容还是非常完善的，涵盖了mall项目最佳学习路线、整体框架搭建、业务与技术实现全方位解析、线上Docker环境部署、微服务项目学习等内容，你也可以点击链接 mall视频教程 了解更多内容。 推荐阅读
上一篇：微博淘宝客推广核心技巧,破零从这里开始! 下一篇：晚上总是加班,白天上班迟到,可以吗? |
