Backend Development 9 min read

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.

macrozheng
macrozheng
macrozheng
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.

debuggingJavaMySQLORMMyBatis-PlusLocalDateTimeConnector-Java
macrozheng
Written by

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.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.