Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for property paths when using fluent API projections. #2329

Closed
mp911de opened this issue Oct 8, 2021 · 0 comments
Closed

Add support for property paths when using fluent API projections. #2329

mp911de opened this issue Oct 8, 2021 · 0 comments
Assignees
Labels
type: enhancement A general enhancement

Comments

@mp911de
Copy link
Member

mp911de commented Oct 8, 2021

#2294 introduced the Fluent API. However this change is incomplete as the to be projected/selected properties and property paths are not considered. Out of spring-projects/spring-graphql#87 we want to:

  • Eagerly materialize joins if a property is explicitly included
  • Avoid joins if a projection is defined and the property is not included
@mp911de mp911de added the type: enhancement A general enhancement label Oct 8, 2021
schauder added a commit that referenced this issue Oct 26, 2021
…aph.

When a property path based projection is specified we still return the root entity.
But we do provide a fetchgraph.
The JPA implementation will (should) load only the specified attributes eagerly.
It most likely will also load all other attributes from all selected tables.

Once we have infrastructure in place for for multilevel projections the same approach can and should be used for those.
Currently this is not the case.

Closes #2329
See spring-projects/spring-data-commons#2420
schauder added a commit that referenced this issue Oct 27, 2021
…aph.

When a property path based projection is specified we still return the root entity.
But we do provide a fetchgraph.
The JPA implementation will (should) load only the specified attributes eagerly.
It most likely will also load all other attributes from all selected tables.

Once we have infrastructure in place for for multilevel projections the same approach can and should be used for those.
Currently this is not the case.

See #2329
See spring-projects/spring-data-commons#2420
schauder added a commit that referenced this issue Oct 28, 2021
Remove superfluous `this.`.
Fix a broken test.

See #2329
@mp911de mp911de assigned schauder and unassigned gregturn Oct 29, 2021
@mp911de mp911de added this to the 2.6 GA (2021.1.0) milestone Oct 29, 2021
mp911de pushed a commit that referenced this issue Oct 29, 2021
…aph.

When a property path based projection is specified we still return the root entity.
But we do provide a fetchgraph.
The JPA implementation will (should) load only the specified attributes eagerly.
It most likely will also load all other attributes from all selected tables.

Once we have infrastructure in place for for multilevel projections the same approach can and should be used for those.
Currently this is not the case.

Closes #2329
Original pull request: #2345.
mp911de added a commit that referenced this issue Oct 29, 2021
Rename Projector to EntityGraphFactory. Remove QuerydslProjector and TypedQueryProjector. Remove MappingContext creation.

See #2329
Original pull request: #2345.
gregturn pushed a commit that referenced this issue Nov 4, 2021
Rename Projector to EntityGraphFactory. Remove QuerydslProjector and TypedQueryProjector. Remove MappingContext creation.

See #2329
Original pull request: #2345.
gregturn added a commit that referenced this issue Nov 4, 2021
For some reason, EclipseLinkNamespaceUserRepositoryTests freezes. Can't figure out the source, so we are disabling it for now.

See #2329
Original pull request: #2345.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
3 participants