How to Seamlessly Replace MyBatis with MyBatis-Plus and Fix LocalDateTime Errors

MyBatis replaced by MyBatis-Plus

Background

An old project uses MySQL 5.7, MyBatis 3.5.0 and mysql‑connector‑java 5.1.26.

MyBatis‑Plus replacement steps

Prepare a table tbl_order and insert two rows.

Running com.qsl.OrderTest#orderListAllTest throws the exception “Conversion not supported for type java.time.LocalDateTime”.

The root cause is that MyBatis 3.5.1 stopped handling LocalDateTime, LocalDate, and LocalTime conversions, delegating them to the JDBC driver. The bundled mysql‑connector‑java 5.1.26 does not support these types.

Upgrading mysql‑connector‑java to 5.1.37 adds support for the missing types, and the test runs successfully.

Upgrade mysql‑connector‑java

After upgrading to version 5.1.37, the previous exception disappears and query results are correct.

Analyzing the exception

Inspecting the stack trace shows that MyBatis 3.5.0 handled LocalDateTime conversion internally, while 3.5.1 handed the conversion to the driver, which lacked support until version 5.1.37.

Storm after deployment

Inserting a new record:

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

triggered a NullPointerException because getTimestamp(columnIndex) returned NULL.

Upgrading mysql‑connector‑java further to 5.1.42 resolves the issue.

Bug in file validation

Background

The system generates main files and dependent auxiliary files. The auxiliary file generation checks whether its required main files have been generated.

Before optimization

The validation logic incorrectly passed if *any* main file existed, not requiring all of them.

After optimization

The logic was corrected to require every main file before allowing auxiliary file generation.

However, after a production upgrade, a previously hidden data inconsistency surfaced: an auxiliary file failed because its dependency field contained a literal filename (e.g., abc_{yyyyMMdd}.txt) instead of a numeric ID.

Conclusion

Component upgrades or legacy code changes can have far‑reaching effects. When possible, avoid unnecessary changes; if changes are required, comprehensive testing is essential to prevent cascading failures.