Skip to content

Qualify child aggregate columns with the table they are selected from - #2395

Open
Develop-KIM wants to merge 1 commit into
spring-projects:mainfrom
Develop-KIM:issue/2112-nested-paths
Open

Develop-KIM wants to merge 1 commit into
spring-projects:mainfrom
Develop-KIM:issue/2112-nested-paths

Conversation

@Develop-KIM

Copy link
Copy Markdown
Contributor

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 AggregatePath works 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:

... LEFT OUTER JOIN referenced_entity ref ON ref.dummy_entity = dummy_entity.id1
    LEFT OUTER JOIN second_level_referenced_entity ref_further ON ref_further.referenced_entity = ref.x_l1id
WHERE dummy_entity.x_something = :x_something

The joins for both levels are there, but the predicate points at the root table, which has no such column. With this change:

WHERE ref_further.x_something = :x_something

and Sort.by("ref.further.something") renders ORDER BY ref_further.x_something ASC instead of ORDER 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 the Criteria/Sort path 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 both Criteria and Sort), all four red on main, plus the existing end-to-end case in AbstractJdbcAggregateTemplateIntegrationTests. Verified with ./mvnw -pl spring-data-jdbc -am verify on 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.

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

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: waiting-for-triage An issue we've not yet triaged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants