-
Notifications
You must be signed in to change notification settings - Fork 617
Add support to define target node class for projections to support multilevel projections with inheritance #2621
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
Comments
Could you elaborate on your use-case for introducing inheritance at the projection level? Also, sorry for the (very) late reply here. |
So first of all: As far as i understood, projections are used to save and load subgraphs as we would have to save the whole graph if the graph data is strongly connected. So let's assume i store vehicles of different kinds with relationships to owning entities like people or companies. And those entities do have relations as well. I have Node classes for the different vehicle types that have different attributes. Now i want to store a fleet of vehicles for such an entity using projections to only store and update those nodes and relationships contained in that projection instead of the whole graph as it might be strongly connected. So i think a CarProjection should be mapped to the CarNode subtype of VehicleNodes. And i want to map VehicleNodes that are of a certain type to their respective projection Nodes. Currently this doesn't seem to be possible. |
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.
…#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.
…#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.
Problem:
Given the following Node definitions:
There is no way to define a multi-level projection for Foo and Bar/BarBar that can be saved or queried, because sdn can't determine to which subtype the projection should be mapped and vice versa. e.g.: The following wont work:
Querying will result in an exception as well because the mapping information is missing.
The text was updated successfully, but these errors were encountered: