Why Switching to MyBatis‑Plus Can Break LocalDateTime Handling and How to Fix It

MyBatis‑Plus Replaces MyBatis

An old project 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 3.1.1 while keeping the same JDBC driver.

After preparing a tbl_order table with two rows, the demo runs com.qsl.OrderTest#orderListAllTest and fails with the exception "Conversion not supported for type java.time.LocalDateTime". The root cause is that mysql‑connector‑java 5.1.26 does not support LocalDateTime.

Upgrading mysql‑connector‑java to 5.1.37 eliminates the exception and the query returns correct results.

Further analysis shows that MyBatis 3.5.1 stopped handling LocalDateTime, LocalDate, and LocalTime conversions internally and delegated them to the JDBC driver. Since mysql‑connector‑java 5.1.26 lacks support for these types, the conversion fails. Version 5.1.37 adds the necessary support.

Summary of the root cause: MyBatis 3.5.1 no longer processes LocalDateTime/LocalDate/LocalTime, and mysql‑connector‑java versions prior to 5.1.37 do not support these types.

Fixed the "Wrong" Bug

After the version upgrade, inserting a record with a NULL timestamp caused a NullPointerException. Upgrading mysql‑connector‑java further to 5.1.42 resolved the issue.

The experience demonstrates that component upgrades or code changes can have far‑reaching effects.

Key Takeaways : avoid unnecessary changes, thoroughly test when modifications are unavoidable, and be aware that a seemingly simple upgrade may trigger hidden bugs.

In addition, the article briefly describes a separate production incident where a validation bug in file generation logic caused a failure after an optimization, illustrating the importance of aligning code logic with business requirements.

Overall, the piece emphasizes careful version management, deep debugging using stack traces, and comprehensive testing to prevent cascading failures.