Check for type compatibility of parameter types with their corresponding entity properties [DATACMNS-372]

[spring-projects-issues]

Thomas Darimont opened DATACMNS-372 and commented

At present we ensure at bootstrapping time that every property that is derived from a Repository finder method like findByFirstnameAndLastname(String firstname, String lastname) -> firstname, lastname is present on the persistent entity.

An additional check that we currently do not do would be to test whether the type of the corresponding parameter of that particular finder method is compatible with the type of the property of the persistent entity.

This would allow us to find potential errors at bootstrapping time findByFirstnameAndLastname(Float firstname, Double lastname).

In addition to that this check could also be added to the SD support in the STS IDE

---

No further details from DATACMNS-372

[jmsmg]

Hi, I'd like to work on this one. Before sending a PR, here is a quick outline of what I have in mind, since the wrong flavour of this check could break existing repositories.

Current state: PartTree validates that every derived property exists, and PartTreeJpaQuery.validate additionally checks the argument count and collection-vs-scalar shape, but no module checks that a scalar argument's type is compatible with the property type. So findByFirstname(Float firstname) still bootstraps fine and only fails at execution time.

Proposal: a commons-level, bootstrap-time check (a helper next to PartTree that store modules invoke where they create their PartTree-based query, as JPA already does for the argument count) that, for each Part whose argument is compared against the property value (SIMPLE_PROPERTY, NEGATING_SIMPLE_PROPERTY, LESS_THAN/GREATER_THAN and their _EQUAL variants, BEFORE/AFTER, BETWEEN), compares the bindable parameter type with PropertyPath#getType(), so collection properties are compared against their component type. Both sides are boxed first and considered compatible when they are assignable in either direction or belong to the same family (Number, CharSequence, Temporal/Date/Calendar, Enum vs String); anything else is reported. String operators (LIKE, CONTAINING, REGEX, ...), IN/NOT_IN (the element type isn't available through Parameter#getType()), geo operators and argument-less operators are skipped, and so is a parameter typed as Object (erased type variables).

Open question: should a mismatch fail bootstrapping with an IllegalArgumentException, consistent with the existing JPA argument validation, or be logged as a warning first, given that some modules convert arguments through a ConversionService? I'd lean towards failing, since the rules above only flag combinations that can't reasonably be converted, but I'm happy to go with a warning if you prefer.

If that direction works for you, I'll send a PR with unit tests.