Migrating MyBatis to MyBatis-Plus: Debugging LocalDateTime Conversion Issues
When migrating an old Java project from MyBatis 3.5.0 to MyBatis‑Plus 3.1.1, a test failed with “Conversion not supported for type java.time.LocalDateTime” because MyBatis 3.5.1 stopped handling Java 8 time types and the existing mysql‑connector‑java 5.1.26 driver lacked support, which was resolved by upgrading the connector to version 5.1.37 or later, highlighting the need for thorough compatibility testing during framework upgrades.
An old Java project used MySQL 5.7, MyBatis 3.5.0 and mysql‑connector‑java 5.1.26. A new developer replaced MyBatis with MyBatis‑Plus 3.1.1, keeping the same connector version.
Running the test com.qsl.OrderTest#orderListAllTest caused an exception: Conversion not supported for type java.time.LocalDateTime . The root cause was identified as MyBatis 3.5.1 no longer handling LocalDateTime , LocalDate , and LocalTime conversions, delegating the task to the JDBC driver.
The mysql‑connector‑java 5.1.26 driver does not support these Java 8 time types. Upgrading the driver to 5.1.37 (or later 5.1.42) restored support and eliminated the exception.
Key steps demonstrated:
1. Insert a record into tbl_order :
INSERT INTO `tbl_order` VALUES (3, 'asdfgh', NULL, '2024-02-21 20:01:31.111', '2024-02-21 20:02:56.764');2. Re‑run com.qsl.OrderTest#orderListAllTest after upgrading the connector.
The case highlights that changing a component (MyBatis → MyBatis‑Plus) can expose hidden incompatibilities in dependent libraries. Thorough testing and awareness of version‑specific behavior are essential when upgrading backend frameworks.
Java Tech Enthusiast
Sharing computer programming language knowledge, focusing on Java fundamentals, data structures, related tools, Spring Cloud, IntelliJ IDEA... Book giveaways, red‑packet rewards and other perks await!
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.