Optimize derived queries to avoid unnecessary JOINs for association ID access

[academey]

Summary

This PR optimizes derived query methods to avoid unnecessary JOINs when accessing association IDs. The implementation consolidates approaches from both this PR and PR #3922 into a unified solution with improved abstraction.

Background

Starting from Hibernate 6.4.1, entity path traversal (e.g., author.id) generates JOINs even when accessing only the ID field. This affects query performance and generates suboptimal SQL for common patterns like findByAuthorId.

Solution

Unified Architecture

• PathOptimizationStrategy: Interface for optimizing property path traversal
• JpaMetamodelContext: Metamodel abstraction compatible with AOT compilation
• DefaultPathOptimizationStrategy: Implementation using SingularAttribute.isId() for reliable ID detection

Implementation

• Modified QueryUtils to use unified optimization strategy
• Updated JpqlUtils to share the same optimization logic
• Eliminated code duplication between Criteria API and JPQL generation
• Uses proven ID detection approach from PR Remove unnecessary join when filtering on relationship id #3922

Examples

Before optimization:

-- findByAuthorId(1L) 
SELECT b FROM Book b JOIN b.author a WHERE a.id = 1

After optimization:

-- findByAuthorId(1L)
SELECT b FROM Book b WHERE b.author.id = 1

Features

• Handles @manytoone relationships
• Supports owning-side @OnetoOne relationships
• Works with composite ID scenarios
• Compatible with derived queries: findByAuthorId, countByProfileId, etc.
• AOT compilation support
• Graceful fallback when metamodel unavailable

Testing

• Added comprehensive unit tests for optimization strategy
• Integration tests verify SQL generation improvements
• Tested with both Hibernate and EclipseLink providers
• All existing tests continue to pass

Performance Impact

This optimization eliminates unnecessary JOINs in common query patterns:

• Simpler SQL execution plans
• Better utilization of foreign key indexes
• Consistent behavior across query generation methods
• No breaking changes to existing functionality

Compatibility

• Works with Hibernate 6.4+ where the issue manifests
• Maintains compatibility with other JPA providers
• No changes required for existing application code
• Backward compatible with all Spring Data JPA versions

Fixes #3349

[mp911de]

This is similar to #3922. Now with the fixes in Hibernate in place we can continue with both pull requests.

[academey]

@mp911de Thank you for your review! I see that #3922 addresses the same issue.
I've reviewed their approach and noticed they modify QueryUtils directly, while my implementation focuses on JpqlUtils.

Would it be valuable to

1. Contribute my test cases to strengthen the validation?
2. Compare both approaches to see if there are complementary insights?

Happy to collaborate or close this in favor of #3922 if that's preferred.
Thanks

[mp911de]

Derived queries use a slightly different API that is however derived from Query utils basically duplicating code. We tried to use less JPA API to determine what we need to know for joining, especially that we use similar code for AOT processing where we have a limited metamodel. Feel free to consolidate both variants into a single PR and introduce a better abstraction or design if you like. Am 11. Aug. 2025, 16:34 +0200 schrieb Hyunjoon Park ***@***.***>:

…

academey left a comment (spring-projects/spring-data-jpa#3970) @mp911de Thank you for your review! I see that #3922 addresses the same issue. I've reviewed their approach and noticed they modify QueryUtils directly, while my implementation focuses on JpqlUtils. Would it be valuable to 1. Contribute my test cases to strengthen the validation? 2. Compare both approaches to see if there are complementary insights? Happy to collaborate or close this in favor of #3922 if that's preferred. Thanks — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[academey]

Thank you for the clarification and the opportunity to improve the design! I understand that

Derived queries and regular queries use different but duplicated code paths. There's a need to minimize JPA API usage for AOT processing. A unified abstraction would be beneficial

I'll review #3922's approach and work on consolidating both solutions.
My plan is that.

1. Study both QueryUtils and JpqlUtils implementations
2. Design a common abstraction that works for both use cases
3. Ensure minimal JPA API usage for AOT compatibility
4. Combine the test cases from both PRs

I'll update this PR with the consolidated solution. Thank you

[academey]

@mp911de I've completed the unified implementation as discussed. The key changes include

• Introduced PathOptimizationStrategy interface for abstraction
• Created DefaultPathOptimizationStrategy that incorporates the approach from PR Remove unnecessary join when filtering on relationship id #3922
• Added JpaMetamodelContext to minimize JPA API exposure and support AOT scenarios
• Integrated comprehensive test cases covering various optimization scenarios

The implementation now provides a clean abstraction layer that can be extended for different optimization strategies while maintaining compatibility with AOT compilation.