Skip to content

GH-2621: Recursively apply DtoInstantiating converter for fluent ops. #2667

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

Merged
merged 1 commit into from
Feb 10, 2023

Conversation

michael-simons
Copy link
Collaborator

This allows to use Dto based projections to be used in a nested fashion when using the fluent save operations.

This does not solve - or attempt to solve - the issue that we don’t have any information what concrete projection class to be used when projection in all cases.

In the test nestedProjectWithFluentOpsShouldWork we could argue that the concrete value can be used to determine the type information. However, while that can be made to work with heterogeneous collections, it would bring a big performance penalty, getting new persistent entity instances and property accessors all the time.

Thus, this change now makes sure no exception is thrown when using such inherited projections, but does explicitly not bring support for deriving the projected properties from them accross an inheritance hierachy.

For more information, please read the comments in org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork and org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork2.

This closes #2621.

This allows to use Dto based projections to be used in a nested fashion when using the fluent save operations.

This does not solve - or attempt to solve - the issue that we don’t have any information what concrete projection class to be used when projection in all cases.

In the test `nestedProjectWithFluentOpsShouldWork` we could argue that the concrete value can be used to determine the type information. However, while that can be made to work with heterogeneous collections, it would bring a big performance penalty, getting new persistent entity instances and property accessors all the time.

Thus, this change now makes sure no exception is thrown when using such inherited projections, but does explicitly not bring support for deriving the projected properties from them accross an inheritance hierachy.

For more information, please read the comments in org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork and org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork2.

This closes #2621.
@michael-simons michael-simons merged commit 5d1241e into 6.3.x Feb 10, 2023
@michael-simons michael-simons deleted the issue/2621 branch February 10, 2023 08:02
michael-simons added a commit that referenced this pull request Feb 10, 2023
…#2667)

This allows to use Dto based projections to be used in a nested fashion when using the fluent save operations.

This does not solve - or attempt to solve - the issue that we don’t have any information what concrete projection class to be used when projection in all cases.

In the test `nestedProjectWithFluentOpsShouldWork` we could argue that the concrete value can be used to determine the type information. However, while that can be made to work with heterogeneous collections, it would bring a big performance penalty, getting new persistent entity instances and property accessors all the time.

Thus, this change now makes sure no exception is thrown when using such inherited projections, but does explicitly not bring support for deriving the projected properties from them accross an inheritance hierachy.

For more information, please read the comments in org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork and org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork2.

This closes #2621.
michael-simons added a commit that referenced this pull request Feb 10, 2023
…#2667)

This allows to use Dto based projections to be used in a nested fashion when using the fluent save operations.

This does not solve - or attempt to solve - the issue that we don’t have any information what concrete projection class to be used when projection in all cases.

In the test `nestedProjectWithFluentOpsShouldWork` we could argue that the concrete value can be used to determine the type information. However, while that can be made to work with heterogeneous collections, it would bring a big performance penalty, getting new persistent entity instances and property accessors all the time.

Thus, this change now makes sure no exception is thrown when using such inherited projections, but does explicitly not bring support for deriving the projected properties from them accross an inheritance hierachy.

For more information, please read the comments in org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork and org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork2.

This closes #2621.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant