Backend Development 10 min read

Replacing MyBatis with MyBatis‑Plus: Debugging Conversion Errors and Version Compatibility

This article walks through migrating an old MySQL‑5.7 project from MyBatis 3.5.0 to MyBatis‑Plus 3.1.1, explains the "Conversion not supported for type java.time.LocalDateTime" exception, shows how upgrading mysql‑connector‑java resolves the issue, and shares lessons learned from a production bug caused by an over‑optimistic validation change.

Top Architect
Top Architect
Top Architect
Replacing MyBatis with MyBatis‑Plus: Debugging Conversion Errors and Version Compatibility

Background: an existing project uses MySQL 5.7, MyBatis 3.5.0, and mysql‑connector‑java 5.1.26. A new developer finds MyBatis cumbersome and decides to replace it with MyBatis‑Plus 3.1.1 while keeping the other components unchanged.

Demo setup: a table tbl_order is created with two rows. A simple MyBatis‑Plus demo is built to simulate the replacement process.

First run of com.qsl.OrderTest#orderListAllTest throws an exception: Conversion not supported for type java.time.LocalDateTime . The stack trace shows the cause originates from the JDBC driver, not MyBatis‑Plus.

Investigation reveals that MyBatis 3.5.1 (used in the demo) stopped handling LocalDateTime , LocalDate , and LocalTime conversions, delegating them to the JDBC driver. The driver version 5.1.26 does not support these Java 8 time types, leading to the error.

Solution: upgrade mysql‑connector‑java to 5.1.37 (or later). After the upgrade the exception disappears and query results are correct.

Further debugging shows that inserting a new record with a NULL timestamp can cause a NullPointerException if the driver returns NULL . The fix is to ensure the driver version that supports the time types is used (e.g., 5.1.42).

Additional case: a production bug where a file‑validation routine incorrectly considered the presence of any main file sufficient, leading to corrupted data being accepted. The validation logic was tightened, but the change introduced a new failure when a dependent file name was stored in a numeric field, exposing the importance of comprehensive testing after component upgrades.

Lesson: upgrading components or refactoring legacy code can have far‑reaching side effects. Prefer not to change stable code unless necessary, and when changes are required, perform thorough testing across all affected modules.

Note: the latter part of the original article contains promotional material for AI/ChatGPT communities and related services, which is not part of the technical discussion.

debuggingJavaMySQLORMMyBatis-Plusversion compatibility
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

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.