Why MyBatis‑Plus Replacement Failed: Debugging LocalDateTime Issues and Connector Upgrades

Background

An existing project uses MySQL 5.7.36, MyBatis 3.5.0, and mysql‑connector‑java 5.1.26.

Replacing MyBatis with MyBatis‑Plus

A new developer finds MyBatis cumbersome and decides to switch to MyBatis‑Plus 3.1.1 while keeping other component versions unchanged. A demo table tbl_order is created with two initial rows.

First Failure

Running com.qsl.OrderTest#orderListAllTest throws an exception: Conversion not supported for type java.time.LocalDateTime . The stack trace shows the issue originates from the JDBC driver.

Root Cause Analysis

The original MyBatis 3.5.0 handled LocalDateTime conversion internally, but the mysql‑connector‑java 5.1.26 driver does not support this type. Upgrading the driver to 5.1.37 adds support, eliminating the exception.

Connector Upgrade

After upgrading mysql‑connector‑java to 5.1.37, the test runs successfully and returns correct query results.

New Issue After MyBatis Upgrade

When MyBatis is upgraded to 3.5.1 (via MyBatis‑Plus), the same Conversion not supported for type java.time.LocalDateTime error reappears. MyBatis 3.5.1 no longer handles LocalDateTime, LocalDate, and LocalTime conversions, delegating them to the JDBC driver, which still lacks support in versions prior to 5.1.37.

Further Production Bug

After fixing the connector issue, a separate production bug emerges in a file‑generation validation routine. The original validation incorrectly passed when any main file existed; it was corrected to require all main files. However, the change unintentionally allowed dirty data where a dependent file stored the filename (e.g., abc_{yyyyMMdd}.txt) instead of the expected numeric ID, causing a new failure.

Conclusion

Component upgrades and code changes can have cascading effects. Avoid unnecessary modifications, ensure thorough testing, and be prepared to trace exceptions back to their root causes.