Why Replacing MyBatis with MyBatis-Plus Triggers LocalDateTime Errors—and How to Fix Them

Background

An existing Java project uses MySQL 5.7.36, MyBatis 3.5.0, and mysql-connector-java version 5.1.26.

Motivation

A new developer finds MyBatis verbose and decides to replace it with MyBatis‑Plus for a more concise API.

Migration Steps

A table tbl_order is created and populated with two rows. A demo project is built using MyBatis‑Plus 3.1.1 while keeping other component versions unchanged.

Encountered Exception

Running com.qsl.OrderTest#orderListAllTest throws the exception "Conversion not supported for type java.time.LocalDateTime". The stack trace points to the JDBC driver.

Root‑Cause Analysis

MyBatis 3.5.0 handled LocalDateTime conversion internally, but MyBatis 3.5.1 (used after the switch) delegates conversion to the JDBC driver. The mysql-connector-java 5.1.26 does not support LocalDateTime, LocalDate, or LocalTime, causing the failure.

Fix by Upgrading JDBC Driver

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

Further Production Issue

Two days after deployment, inserting a record with a NULL timestamp caused a NullPointerException. The problem was traced to the same driver limitation; upgrading to mysql-connector-java 5.1.42 resolved it.

INSERT INTO tbl_order VALUES (3, 'asdfgh', NULL, '2024-02-21 20:01:31.111', '2024-02-21 20:02:56.764');

Additional Bug and Refactoring

The article also describes a validation bug where auxiliary file generation passed when only one main file existed. The logic was corrected to require all main files before allowing auxiliary generation.

Conclusion

Component upgrades can have far‑reaching side effects; avoid unnecessary changes, and when changes are required, perform comprehensive testing to catch hidden incompatibilities.