When a New Developer Swapped MyBatis for MyBatis‑Plus and Got Scolded by the Team Lead

Background

An old project uses MySQL 5.7.36, MyBatis 3.5.0, and mysql-connector-java 5.1.26.

Motivation for Change

A newly joined developer finds MyBatis verbose and decides to replace it with MyBatis‑Plus 3.1.1, keeping all other component versions unchanged.

Initial Replacement Demo

A table tbl_order is created with two rows. The demo runs com.qsl.OrderTest#orderListAllTest and throws an exception:

Conversion not supported for type java.time.LocalDateTime

Root‑Cause Analysis

Inspecting the stack trace reveals that mysql-connector-java 5.1.26 does not support java.time.LocalDateTime. Upgrading the driver to 5.1.37 adds support for LocalDateTime, LocalDate, and LocalTime, after which the test passes.

Why the Issue Appeared After Replacement

The project’s MyBatis version displayed as 3.5.1 (not the original 3.5.0). MyBatis 3.5.1 stopped handling LocalDateTime conversion internally and delegated it to the JDBC driver, which the old driver could not handle. The change in LocalDateTimeTypeHandler between 3.5.0 and 3.5.1 explains the new failure.

Further Production Incident

After upgrading mysql-connector-java to 5.1.42, a production bug surfaced during file generation. The original validation logic ( listFileGenerateLog) incorrectly passed when *any* main file existed, violating the business rule that *all* main files must be generated.

The validation was rewritten to require every main file, fixing the logical bug.

Later, an auxiliary file failed because its dependency field contained a filename (e.g., abc_{yyyyMMdd}.txt) instead of the expected numeric ID, a data corruption that the previous buggy validation had silently accepted.

Takeaways

Component upgrades or code adjustments can have far‑reaching side effects. If a change is not essential, it is safer to avoid it; otherwise, thorough testing is mandatory to prevent hidden bugs from surfacing in production.