👉 这是一个或许对你有用的社群
🐱 一对一交流/面试小册/简历优化/求职解惑,欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料:
《项目实战(视频)》:从书中学,往事中“练”
《互联网高频面试题》:面朝简历学习,春暖花开
《架构 x 系统设计》:摧枯拉朽,掌控面试高频场景题
《精进 Java 学习指南》:系统学习,互联网主流技术栈
《必读 Java 源码专栏》:知其然,知其所以然
👉这是一个或许对你有用的开源项目
国产 Star 破 10w+ 的开源项目,前端包括管理后台 + 微信小程序,后端支持单体和微服务架构。
功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号等等功能:
Boot 仓库:https://gitee.com/zhijiantianya/ruoyi-vue-pro
Cloud 仓库:https://gitee.com/zhijiantianya/yudao-cloud
视频教程:https://doc.iocoder.cn
【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本
背景简介
在一个老项目中,数据库采用的是 MySQL 5.7.36,ORM 框架使用的是 MyBatis 3.5.0,而 mysql-connector-java
的版本是 5.1.26。
有一天,一个精力充沛、充满折腾精神的年轻人加入了项目。
他觉得 MyBatis 的使用不够简单,需要写的代码比较多,因此认为有必要将其替换为 MyBatis-Plus。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址:https://github.com/YunaiV/ruoyi-vue-pro
视频教程:https://doc.iocoder.cn/video/
MyBatis-Plus 替换 MyBatis
首先,我们准备了一张名为 tbl_order 的表,并初始化了其中的两条数据。
DROP TABLE IF EXISTS `tbl_order`;
CREATE TABLE `tbl_order` (
`id` bigint(0) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`order_no` varchar(50) NOT NULL COMMENT '订单号',
`pay_time` datetime(3) DEFAULT NULL COMMENT '付款时间',
`created_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '创建时间',
`updated_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '最终修改时间',
PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB COMMENT = '订单';
INSERT INTO `tbl_order` VALUES (1, '123456', '2024-02-21 18:38:32.000', '2024-02-21 18:37:34.000', '2024-02-21 18:40:01.720');
INSERT INTO `tbl_order` VALUES (2, '654321', '2024-02-21 19:33:32.000','2024-02-21 19:32:12.020', '2024-02-21 19:34:03.727');
为了简化演示,我们直接使用 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
❞
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址:https://github.com/YunaiV/yudao-cloud
视频教程:https://doc.iocoder.cn/video/
升级 mysql-connector-java
我们将 mysql-connector-java
升级到 5.1.37,然后再次执行 com.qsl.OrderTest#orderListAllTest
。
这次不再报异常,并且查询结果也是正确的。
看起来,MyBatis-Plus 替换 MyBatis 的任务完成了。
这一切都如此顺利,让人有些怀疑。
让我们再回头看看之前提到的异常:
Conversion not supported for type java.time.LocalDateTime
在替换 MyBatis 之前并没有这个异常,但在替换之后就出现了这个异常,这难道不是 MyBatis-Plus 的问题吗?
那么如何找到这个异常的根本原因呢?
其实很简单,直接从异常堆栈入手。
点击后,你会发现代码非常简单。
这么简单的代码怎么会有问题呢?
大家请注意图中左上角的 MyBatis 版本,是 3.5.1,而不是最初的 3.5.0。
可能有人会问:「既然替换成了 MyBatis-Plus,为什么还有 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 之前都不支持这些类型。
❞
搞清楚了这个异常的来龙去脉,顺理成章的感觉是不是又回来了?
暴风雨来临
版本上线不到两天,该来的终究还是来了。
我们往表 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 的问题
无意中我看到了这个 issue-1114,是不是和我们之前分析的 “Conversion not supported for type java.time.LocalDateTime
” 是同一个问题?
只是我们使用的数据库连接池是默认的 HikariCP 而非 Druid。
结合 druid/issues/3302
,如果使用 Druid 作为数据库连接池,出现的异常可能与我们之前分析的确实不同。
因此,大家需要根据自己的实际情况进行分析,但对异常的分析方法是通用的。
总结
关于组件的升级或旧代码的调整,都可能引发连锁反应,影响重大。
我的观点是:
❝
能不动就不要动,改好没功劳,改坏要背锅,吃力不讨好,又不是必须要改。
❞
如果不得不改,那就需要全面的测试。
欢迎加入我的知识星球,全面提升技术能力。
👉 加入方式,“长按”或“扫描”下方二维码噢:
星球的内容包括:项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话,在看,转发吧。
谢谢支持哟 (*^__^*)