Why Switching MyBatis to MyBatis‑Plus Triggers LocalDateTime Errors—and How to Resolve Them

Background

A legacy project uses MySQL 5.7.36, MyBatis 3.5.0, and mysql‑connector‑java 5.1.26. A new developer finds MyBatis cumbersome and decides to replace it with MyBatis‑Plus.

Replacing MyBatis with MyBatis‑Plus

First, a simple tbl_order table is created and populated with two rows:

DROP TABLE IF EXISTS `tbl_order`;
CREATE TABLE `tbl_order` (
  `id` bigint 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');

The demo uses MyBatis‑Plus version 3.1.1 while keeping the MySQL connector unchanged.

Error Analysis

Running com.qsl.OrderTest#orderListAllTest throws a TransientDataAccessResourceException with the message "Conversion not supported for type java.time.LocalDateTime". The stack trace shows the failure originates from LocalDateTimeTypeHandler attempting to retrieve a java.time.LocalDateTime value.

Investigation reveals that MyBatis 3.5.1 (the version bundled with MyBatis‑Plus) no longer handles LocalDateTime, LocalDate, or LocalTime conversions internally; it delegates them to the JDBC driver. The existing mysql‑connector‑java 5.1.26 does not support these types, leading to the exception.

Fixing the MySQL Connector

Upgrading mysql‑connector‑java to version 5.1.37 adds support for LocalDateTime, LocalDate, and LocalTime. After the upgrade, the test runs without errors and returns correct query results.

Further Issues and Production Bug

Later, inserting a row with a

NULL

pay_time

triggers another exception because the driver returns NULL for getTimestamp, which can cause a NullPointerException downstream. Upgrading the connector further to 5.1.42 resolves this problem.

Separately, the article describes a file‑generation validation bug. The original validation passed when *any* primary file existed, contradicting business rules that require *all* primary files to be present. The author rewrote the validation logic to enforce the correct requirement. However, after deployment, a production incident occurred: an auxiliary file failed because its dependency field contained a placeholder filename (e.g., abc_{yyyyMMdd}.txt) instead of a numeric ID, exposing dirty data that the previous buggy validation had silently accepted.

Conclusion

Component upgrades or code refactors can have far‑reaching side effects. When possible, avoid unnecessary changes; if changes are required, perform comprehensive testing. Understanding version‑specific behavior—such as MyBatis 3.5.1 delegating date‑time conversion to the JDBC driver—and ensuring compatible driver versions are essential to prevent runtime failures.