Why MyBatis‑Plus Upgrade Triggers LocalDateTime Errors and How to Fix Them

Background: an existing project uses MySQL 5.7.36, MyBatis 3.5.0, and mysql‑connector‑java 5.1.26.

A new, energetic developer decides to replace MyBatis with MyBatis‑Plus 3.1.1 to simplify code and showcase technical skill.

Demo setup: a table tbl_order is created and populated with two rows, then the test com.qsl.OrderTest#orderListAllTest is run, which throws the exception “Conversion not supported for type java.time.LocalDateTime”.

Investigation starts by examining the stack trace, revealing that the mysql‑connector‑java driver does not support LocalDateTime. Upgrading the driver to version 5.1.37 eliminates the exception and returns correct query results.

Further analysis shows that after the replacement the MyBatis version displayed is 3.5.1, not the original 3.5.0. MyBatis 3.5.0 performed the LocalDateTime conversion internally, while 3.5.1 delegates this task to the JDBC driver, which lacked support until connector 5.1.37. Screenshots illustrate the change in LocalDateTimeTypeHandler and the list of supported types, confirming that LocalDateTime, LocalDate, and LocalTime are absent in 5.1.26.

Conclusion of this part: the root cause is MyBatis 3.5.1 no longer handling LocalDateTime conversion, combined with an outdated mysql‑connector‑java version.

Second incident: after fixing the above, a production bug appears when a file‑validation logic is “optimized”. The original validation required all main files to be generated before an auxiliary file could be created, but the “optimized” version incorrectly passes if any main file is generated, violating business rules.

During a later deployment, an auxiliary file fails with an error indicating a missing resource abc_{yyyyMMdd}.txt. Investigation of the database shows that the dependent field contains the literal filename instead of a numeric ID, exposing the earlier validation bug that had silently accepted dirty data for years.

The stack trace again guides the debugging process, revealing that a NULL timestamp leads to a NullPointerException. Upgrading mysql‑connector‑java to 5.1.42 resolves this issue.

Final takeaway: component upgrades or code changes can have far‑reaching side effects; avoid unnecessary modifications, and when changes are unavoidable, conduct comprehensive testing to prevent hidden regressions.

Images illustrating the steps: