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...