Repository navigation
Qualify child aggregate columns with the table they are selected from - #2395
Open
Develop-KIM wants to merge 1 commit into
Open
Develop-KIM wants to merge 1 commit into
Develop-KIM wants to merge 1 commit into
Conversation
A Criteria or Sort referring to a property of a child aggregate rendered the column against the aggregate root's table, so the generated SQL asked for a column the root table does not have. We now resolve the table from the property path, which qualifies such a column with the joined child table. Resolving the table from the AggregatePath covers nested paths too: for ref.further.something the column is qualified with the alias of the second level join, which single query loading already emits. Closes spring-projects#2112 Signed-off-by: Donghwan Kim <kimdonghwan913@gmail.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resubmits #2337, which was closed with "A PR for this should support nested properties".
It turns out the fix already did — resolving the table from the
AggregatePathworks at any depth — the PR just never showed it. So this is the same change with the nested cases covered, rebased on current main.For
Criteria.where("ref.further.something")on current main:The joins for both levels are there, but the predicate points at the root table, which has no such column. With this change:
and
Sort.by("ref.further.something")rendersORDER BY ref_further.x_something ASCinstead ofORDER BY dummy_entity.x_something ASC.The one case that must keep resolving to the root table is an entity-valued property with a custom write target, since its column lives in the owning table rather than in the table of the entity itself.
PartTreeJdbcQueryUnitTests.considersConvertersForQueryArguments(GH-2059) covers that and it stays green.One thing I want to check on scope: derived queries still reject nested paths in
JdbcQueryCreator.validateProperty("Cannot query by nested property"), which is #1227. I read your comment as being about theCriteria/Sortpath this issue is filed against, so I left that alone. If you meant derived queries too, say so and I will look at it separately.Tests: four unit tests in
SqlGeneratorUnitTests(single level and nested, for bothCriteriaandSort), all four red on main, plus the existing end-to-end case inAbstractJdbcAggregateTemplateIntegrationTests. Verified with./mvnw -pl spring-data-jdbc -am verifyon JDK 21: 569 + 592 unit tests and 638 integration tests green. No Docker here, so the integration run covers H2 and HSQLDB only — the other databases were skipped.Written with AI assistance (Claude Code). I reproduced the behaviour, reviewed every line, and ran the verification above myself.