Why Replacing MyBatis with MyBatis‑Plus Can Break Your DateTime Handling

Background

An existing project used MySQL 5.7.36, MyBatis 3.5.0 and mysql‑connector‑java 5.1.26. A new developer, eager to simplify code, decided to replace MyBatis with MyBatis‑Plus 3.1.1 while keeping other components unchanged.

Reproducing the Issue

A table tbl_order was created and populated with two rows. Running the test method com.qsl.OrderTest#orderListAllTest produced the exception:

Conversion not supported for type java.time.LocalDateTime

Root‑Cause Analysis

MyBatis 3.5.1 stopped handling conversions for LocalDateTime, LocalDate and LocalTime. The conversion responsibility was handed over to the JDBC driver. The driver version in use (mysql‑connector‑java 5.1.26) does not support these Java 8 time types, which caused the exception.

Support for the three time types was added starting with mysql‑connector‑java 5.1.37.

Fix

Upgrading the driver to 5.1.37 (or later, e.g., 5.1.42) restores the missing conversion support. After the upgrade, rerunning com.qsl.OrderTest#orderListAllTest no longer throws the exception and query results are correct.

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

Related Observations

The same problem appears in MyBatis‑Plus issue #1114. Using a different connection pool (e.g., Druid) can surface a different stack trace, but the underlying incompatibility remains the same.

Second Case: Validation Logic Bug

Another incident involved a file‑generation service where the original validation logic considered the check passed if *any* main file existed, whereas the business rule required *all* main files to be present. This bug allowed dirty data (e.g., a placeholder file name "abc_{yyyyMMdd}.txt") to slip through, causing a production failure when a dependent file could not be generated.

The validation was rewritten to require that every main file be generated before any dependent file proceeds, eliminating the inconsistency.

Lessons Learned

Component upgrades or seemingly harmless code changes can have far‑reaching effects. Avoid unnecessary modifications, and when changes are unavoidable, perform thorough testing to prevent regressions.