Why Replacing MyBatis with MyBatis‑Plus Can Break Production: A Deep Dive into Version Compatibility

MyBatis to MyBatis‑Plus Migration

Background

An legacy project uses MySQL 5.7, MyBatis 3.5.0 and mysql‑connector‑java 5.1.26. A newly joined developer found MyBatis verbose and decided to replace it with MyBatis‑Plus 3.1.1 while keeping other components unchanged.

Initial Replacement and Failure

A demo table tbl_order with two rows was created and a simple MyBatis‑Plus demo (named play_it_safe) was built to simulate the replacement.

Running com.qsl.OrderTest#orderListAllTest raised the exception "Conversion not supported for type java.time.LocalDateTime".

The underlying reason was that mysql‑connector‑java 5.1.26 does not support conversion of java.time.LocalDateTime (or LocalDate, LocalTime) to SQL types.

Fixing the Connector Version

Upgrading mysql‑connector‑java to version 5.1.37 eliminated the exception and the query returned correct results.

Root‑Cause Analysis

MyBatis 3.5.0 internally handled LocalDateTime → java.sql.Timestamp conversion. Starting with MyBatis 3.5.1 this handling was removed and the conversion was delegated to the JDBC driver.

Since mysql‑connector‑java versions prior to 5.1.37 lack support for these types, the error appears after the migration to MyBatis‑Plus (which depends on MyBatis 3.5.1).

Further Issues – "Bug Not Meant to Fix"

After the connector upgrade, inserting a record with datetime values caused getTimestamp(columnIndex) to return NULL, leading to a NullPointerException during result processing.

Upgrading mysql‑connector‑java further to 5.1.42 resolved this secondary issue.

Another Incident – Validation Logic Bug

Later, an optimization changed the file‑generation validation logic. The original logic considered the check passed if any main file existed, which conflicted with the business rule that *all* main files must be generated.

The corrected logic required every main file to be present before generating auxiliary files.

However, after deployment a production error showed that a file name pattern abc_{yyyyMMdd}.txt had been stored in a numeric field, allowing the buggy validation to pass on dirty data and causing a later failure.

Takeaways

Component upgrades or code changes can have far‑reaching side effects; thorough testing is essential.

If a change is unavoidable, verify version compatibility and understand the underlying library behavior to avoid hidden regressions.

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

Author: 青石路 Source: https://www.cnblogs.com/youzhibing/p/18019399 Copyright notice: Content is for learning and research only; original copyright belongs to the author.