Skip to content

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

Closed
NilsWild opened this issue Oct 27, 2022 · 2 comments
Assignees
Labels
type: enhancement A general enhancement

Comments

@NilsWild
Copy link

Problem:
Given the following Node definitions:

@Node
class Foo (
        val bar: Bar
        ) {
    @Id
    var id: UUID = UUID.randomUUID()
}

@Node
open class Bar(
    val value1: String
) {
    @Id
    var id: UUID = UUID.randomUUID()
}

@Node
open class BarBar(value1: String, val value2: String): Bar(value1)

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:

class FooProjection(
    val bar: BarProjection
)

open class BarProjection(
    val value1: String
)

open class BarBarProjection(value1: String, val value2: String): BarProjection(value1)

val barBarProjection = BarBarProjection("v1", "v2")
val fooProjection = FooProjection(barBarProjection)
neo4jTemplate.save(Foo::class.java).one(fooProjection)

Querying will result in an exception as well because the mapping information is missing.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Oct 27, 2022
@meistermeier meistermeier self-assigned this Nov 1, 2022
@meistermeier
Copy link
Collaborator

Could you elaborate on your use-case for introducing inheritance at the projection level?
The basic idea of having this support is to cover specific loading (and saving) scenarios.

Also, sorry for the (very) late reply here.

@meistermeier meistermeier added status: waiting-for-feedback We need additional information before we can continue and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 20, 2023
@NilsWild
Copy link
Author

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.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 26, 2023
michael-simons added a commit that referenced this issue Feb 9, 2023
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 added type: enhancement A general enhancement and removed status: feedback-provided Feedback has been provided labels Feb 9, 2023
michael-simons added a commit that referenced this issue 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 issue 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
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants