Same code, so why doesn't it work? An escape from the Spring JDBC converter maze

To store LocalDate as a string in Spring Data JDBC, a custom converter was registered, but contrary to expectations, it didn't work. A LocalDateTime converter built the same way appeared to work, but in reality this was due to differences in how JDBC handles types, not the converter itself.

The root cause was StatementCreatorUtils.setParameterValue() inside Spring JDBC. Here, if the input value is LocalDate, setDate() is called first, and if it's LocalDateTime, setTimestamp() is called first — the special handling path by Java type takes priority over any previously registered custom converter.

This difference is what caused the divergent results.

• LocalDate + setDate(): Oracle JDBC recognizes it as a DATE type, causing a conflict with the VARCHAR column or converting it into Oracle's default format like 01-AUG-24.
• LocalDateTime + setTimestamp(): Oracle leniently converts the Timestamp to a string when storing it, making it appear to work normally.

The attempts made to solve the problem are also summarized.

• @DateTimeFormat is for binding web request parameters, so it had no effect on DB mapping.
• Using JdbcTemplate directly works, but loses the convenience of Spring Data JDBC.
• Switching to a String field is possible, but blurs the meaning of the entity.

The cleanest solution was to create a CustomLocalDate wrapper class. By wrapping it in a user-defined type that Spring JDBC doesn't treat specially, the custom converter applies normally, and by registering both CustomLocalDateToStringConverter and StringToCustomLocalDateConverter together, bidirectional conversion for storage/retrieval can be reliably controlled.

Finally, since this kind of low-level behavior can vary depending on the DB vendor and JDBC driver version, testing that checks even the stored raw value is necessary before actual production application.