Query with base class will auto use the base class name as label

[abccbaandy]

I have a base class for common field

public abstract class BaseNode {
    @Id
    @GeneratedValue
    private UUID id;
}

My real node

@Node
public class MyNode extends BaseNode {
    @Relationship(type = "CONTAIN", direction = Relationship.Direction.OUTGOING)
    private List<BaseRelationship<BaseNode>> nodeList = new ArrayList<>();
}

@RelationshipProperties
public class BaseDbRelationship<T extends BaseNode> {
    @RelationshipId
    private Long id;
    @TargetNode
    private T node;
}

When I use repository to query the MyNode, it will show cypher like this

MATCH (myNode:`MyNode`) WHERE myNode.id = $__id__ OPTIONAL MATCH (myNode)-[__sr__:`CONTAIN`]->(__srn__:`BaseNode`) WITH collect(elementId(myNode)) AS __sn__, collect(elementId(__srn__)) AS __srn__, collect(elementId(__sr__)) AS __sr__ RETURN __sn__, __srn__, __sr__

And result nodeList is empty, because those node don't have BaseNode label. Anyways to get rid of this feature? I tried removed private UUID id; part but still not work too.

[abccbaandy]

Anyone? @michael-simons

[michael-simons]

The basic working is well documented https://docs.spring.io/spring-data/neo4j/reference/object-mapping/metadata-based-mapping.html#_a_note_on_class_hierarchies and we don't have any plans changing this.

For the other end of the relationship you either need to have the concrete class as type parameter.

We might investigate not to render a label for the other end of relationship if we can only find an abstract. Wdyt, @meistermeier

[meistermeier]

I think that using no label is a no-go here. That's not only that we load a lot of extra data that might be not of interest but also because after the loading happened the mapping logic will use the same approach to determine what to map (a BaseNode in this case) even though there is no label but it's the highest abstraction given this relationship definition. And saying we don't have any plans has to be even stricter in my opinion. We won't change this because it might create unwanted and unneeded load for other users. Although I don't think that we mention this explicitly in the documentation: The most abstract entity that you want to use as a representation of a node should define @Id and @Node. Not mixing the levels where those is defined is typically the better solution.

[abccbaandy]

I don't get it. Why don't it just follow the define? In this case, just search for CONTAIN relation, like this

MATCH (myNode:`MyNode`) WHERE myNode.id = $__id__ OPTIONAL MATCH (myNode)-[__sr__:`CONTAIN`]->(__srn__) WITH collect(elementId(myNode)) AS __sn__, collect(elementId(__srn__)) AS __srn__, collect(elementId(__sr__)) AS __sr__ RETURN __sn__, __srn__, __sr__

@michael-simons The reason I use an BaseNode instead real Node is here https://github.com/spring-projects/spring-data-neo4j/issues/2941#issuecomment-2300426754

(:Parent1)-[r:Parent1_CONTAIN]->(:Child1) (:Parent1)-[r:Parent1_CONTAIN]->(:Child2)

I have the same relation point to different type node, it works well in pure Neo4j(both create/query), but seems in SDN it became strange.