How to Seamlessly Replace MyBatis with MyBatis-Plus and Fix LocalDateTime Errors
This article walks through migrating an existing MySQL‑based Java project from MyBatis 3.5.x to MyBatis‑Plus 3.1.1, diagnosing the LocalDateTime conversion exception, upgrading mysql‑connector‑java, handling subsequent null‑pointer issues, and learning from a related file‑validation bug to emphasize thorough testing during component upgrades.
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_orderand insert two rows.
Running
com.qsl.OrderTest#orderListAllTestthrows the exception “Conversion not supported for type java.time.LocalDateTime”.
The root cause is that MyBatis 3.5.1 stopped handling
LocalDateTime,
LocalDate, and
LocalTimeconversions, 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
LocalDateTimeconversion 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.
macrozheng
Dedicated to Java tech sharing and dissecting top open-source projects. Topics include Spring Boot, Spring Cloud, Docker, Kubernetes and more. Author’s GitHub project “mall” has 50K+ stars.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.