spring-projects
GH-1006 included QueryMappingConfiguration for all part tree queries
Solving #1006 issue
To ease the review - actually, we already had the QueryMappingConfiguration applied for PartTree queries, but only for those that are declared in the repository and execute via PartTreeJdbcQuery#execute. For the predefined methods, that resolve into SimpleJdbcRepository methods we did not have QueryMappingConfiguration applied. So I've just covered this gap and added some tests to verify the expected behavior.
PS: For StringBasedJdbcQuery no changes required.
Resolved the conflict after Iterable --> List return type change for DefaultDataAccessStrategy.
Kind reminder for the review @schauder :)
@schauder
It actually is a bit strange that we have the failure in archunit test for cycles between modules, since only spring-data-jdbc module was affected. I'll give it a look and report below.
There are components (e.g. repository, mapping that exist in various modules. You get circles among these when you have a dependency in one direction in one module (possibly relational or commons) but in the opposite direction in another module (e.g. jdbc)
@schauder so, the dependency error was fixed. The solution was to move QueryMappingConfiguration from:
package org.springframework.data.jdbc.repository;
to
package org.springframework.data.jdbc.core.convert;
It seems to make sense, since the QueryMappingConfiguration is really a part of the core conversion mechanism, not really the repository package.
What are your thoughts on this? @schauder
I updated our labels as this change is a breaking one by moving public types around.
This PR currently does not compile and a naive rebase doesn't work either. Could you take a look @mipo256 please.
While it does compile a ./mvnw clean verify results in test failures. Please fix those.