This is a simple unit test which passes with the 5.3.x
but fails with the current 6.0
milestones:
@Test
void namedParamMapReference() {
String insert = "insert into foos (id) values (:headers[id])";
class Foo {
final Map<String, Object> headers = new HashMap<>();
public Foo() {
this.headers.put("id", UUID.randomUUID());
}
public Map<String, Object> getHeaders() {
return this.headers;
}
}
Foo foo = new Foo();
Object[] params =
NamedParameterUtils.buildValueArray(NamedParameterUtils.parseSqlStatement(insert),
new BeanPropertySqlParameterSource(foo), null);
assertThat(params[0]).isEqualTo(foo.getHeaders().get("id"));
}
The point is that we may have a reference for the value from nested Map
property.
The typical use case is messaging, for example with Spring Integration, where a Message<?>
in the request is used as a source for parameter values.
We even advertise this in the docs: https://docs.spring.io/spring-integration/docs/current/reference/html/jdbc.html#jdbc-outbound-channel-adapter.
I suspect that the cause for breaking change is this fix: https://github.com/spring-projects/spring-framework/commit/64b6beed5b135344b6f0d15bc50bf4c08c2ab9bb. Or the previous one: https://github.com/spring-projects/spring-framework/commit/86eda279c82b79c7888558e7a2524db44c7ee108.
Thanks
Comment From: quaff
parameterName is changed from headers[id]
to headers
after commit https://github.com/spring-projects/spring-framework/commit/64b6beed5b135344b6f0d15bc50bf4c08c2ab9bb
Comment From: rstoyanchev
Maybe consider #17773 as well for potential improvement to the parsing algorithm.
Comment From: jhoeller
With some custom treatment, we can restore the original intent of #27716 as well as preserve square brackets for index/key expressions. Finally making it into RC2...