Replacing MyBatis with MyBatis‑Plus Can Trigger LocalDateTime Conversion Errors

Background

The legacy project used MySQL 5.7, MyBatis 3.5.0 and mysql‑connector‑java 5.1.26. A new developer found MyBatis verbose and decided to replace it with MyBatis‑Plus 3.1.1 while keeping all other components unchanged.

Demo Setup

A simple table tbl_order was created and populated with two rows. The test class com.qsl.OrderTest#orderListAllTest was executed to verify the migration.

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

Running the test produced the following exception:

Conversion not supported for type java.time.LocalDateTime

Root‑Cause Analysis

The stack trace showed that the failure originated from mysql‑connector‑java. The driver version 5.1.26 does not support the JDBC conversion of java.time.LocalDateTime, LocalDate, or LocalTime.

MyBatis 3.5.0 performed the conversion internally, but starting with MyBatis 3.5.1 the conversion was removed and delegated to the JDBC driver. MyBatis‑Plus depends on MyBatis 3.5.1, so after the replacement the conversion responsibility shifted to the driver, exposing the incompatibility.

Documentation of the driver shows that support for these Java 8 time types was added in version 5.1.37:

Fix

Upgrading mysql‑connector‑java to 5.1.37 (or later 5.1.42) restores support for the time types. After the upgrade the same test runs without exception and returns correct query results.

Lessons Learned

Component upgrades can change hidden behaviours; a seemingly harmless ORM replacement introduced a version mismatch that broke time‑type handling. When modifying legacy code, comprehensive testing—including version compatibility checks for JDBC drivers and framework internals—is essential to avoid production incidents.