Why Switching MyBatis to MyBatis‑Plus Triggers LocalDateTime Errors—and How to Resolve Them

Background

An existing Java service used MySQL 5.7.36, 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 other component versions unchanged.

Replacing MyBatis with MyBatis‑Plus

A demo table tbl_order with two rows was created (see image below). The demo runs only MyBatis‑Plus code to simulate the migration.

Running com.qsl.OrderTest#orderListAllTest produced the exception:

Conversion not supported for type java.time.LocalDateTime

The stack trace highlighted that mysql-connector-java did not support LocalDateTime. Upgrading the connector to 5.1.37 eliminated the error and returned correct query results.

Root‑Cause Analysis

Inspecting the stack trace revealed that the project was actually using MyBatis 3.5.1 (shown in the IDE screenshot). MyBatis 3.5.0 handled LocalDateTime conversion internally, but starting with 3.5.1 the conversion was delegated to the JDBC driver.

The official MyBatis change log confirms that LocalDateTime, LocalDate, and LocalTime handling was removed in 3.5.1, requiring the JDBC driver to support these types.

Examining the supported type list for mysql-connector-java 5.1.26 showed that LocalDateTime was absent. The list for version 5.1.37 (and later) includes the missing types, confirming the root cause:

Storm Scenario After Upgrade

Two days after the version change, inserting a new row with a NULL timestamp triggered another exception. Upgrading the connector further to 5.1.42 resolved the issue.

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

Unrelated Validation Bug (Issue 02)

The article also recounts a separate incident where a file‑generation validation logic was flawed: the original check passed if *any* main file existed, contrary to the business rule that *all* main files must be present. The logic was corrected to require every main file before generating dependent files.

Production Exception After Fix

Later that night, a dependent file failed because its reference field contained a placeholder filename (e.g., abc_{yyyyMMdd}.txt) instead of the expected numeric ID. The earlier validation bug had unintentionally allowed this dirty data to pass, and fixing the validation exposed the inconsistency.

Conclusion

Component upgrades—even seemingly minor ones—can cascade into unexpected failures across the stack. The safest approach is to avoid unnecessary changes, perform comprehensive testing when changes are required, and understand how version differences affect underlying behavior such as type conversion.