Migrating from MyBatis to MyBatis-Plus: Resolving LocalDateTime Conversion Errors and Lessons Learned

The author describes a legacy Java project that 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 (version 3.1.1) while keeping other components unchanged.

Preparation

A table tbl_order 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');

A demo project is built with MyBatis‑Plus only to illustrate the migration process.

First Failure

Running the test com.qsl.OrderTest#orderListAllTest throws a TransientDataAccessResourceException with the message:

Conversion not supported for type java.time.LocalDateTime

The full stack trace shows the error originates from MyBatis trying to retrieve a LocalDateTime column.

Root‑Cause Analysis

Two changes are identified:

MyBatis 3.5.1 (used indirectly by MyBatis‑Plus) stopped handling LocalDateTime , LocalDate , and LocalTime conversions internally.

mysql‑connector‑java 5.1.26 does not support these Java 8 time types, so the driver cannot perform the conversion.

Therefore the combination of MyBatis 3.5.1 and the old JDBC driver leads to the exception.

Solution

Upgrading the JDBC driver to a version that supports the new time types fixes the problem. The author first upgrades to mysql‑connector‑java 5.1.37 , reruns the test, and the exception disappears with correct query results.

Later, after inserting a third row with a NULL pay_time , another failure occurs, which is resolved by further upgrading the driver to 5.1.42 .

Additional Anecdote – Unintended Bug After Fix

The article also recounts a separate incident where a validation bug was “fixed” in a file‑generation service. The original logic incorrectly passed when *any* main file existed; the fix required *all* main files to exist. After the change, a production error surfaced because a database record stored a filename string (e.g., abc_{yyyyMMdd}.txt ) instead of a numeric file ID, exposing dirty data that the previous bug had silently tolerated.

The lesson is that seemingly harmless refactors can surface hidden data issues, and thorough testing is essential when modifying components.

Conclusion

Component upgrades—whether a framework like MyBatis‑Plus or a JDBC driver—can have far‑reaching effects. If a change is not strictly necessary, it may be safer to avoid it; otherwise, comprehensive testing and awareness of version‑specific behavior are crucial to prevent regressions.