Direct Relationship Persistence Issue

[pc-dd]

Say I have nodes of types A, B and C, and I have the following graph:

My goal is to load the node A, together with the connected B and C nodes.

Currently (in Kotlin code) I am doing session.load(A::class.java, "a1", -1), which uses this implementation: <T,ID extends Serializable> T load(Class<T> type, ID id, int depth) from https://javadoc.io/static/org.neo4j/neo4j-ogm-core/3.2.3/org/neo4j/ogm/session/Session.html

According to https://neo4j.com/docs/ogm-manual/current/reference/#reference:session:loading-entities:load-depth , providing depth = -1 should make it load the node A together with all its connected nodes. However, it seems to only load the node A.

What is the correct method I should be using to achieve my goal here? I have tried looking into the neo4j OGM documentation, but have not found more information.

Expected Behavior

Expected load to load connected nodes

Current Behavior

Load only loads the initial node but not its connected nodes

Context

Your Environment

• Java version:
• Neo4j version (The version of the database): 5.9.0
• OGM Version (The version of this software): 3.2.23
• OGM Transport used (One of Bolt, HTTP or embedded): Bolt
• Neo4j Java Driver version (in case of Bolt transport): 3.2.23
• Link to your project:

Steps to Reproduce

[pc-dd]

For more context:

@NodeEntity
data class A(
    @Id val id: String? = null,
    @Relationship(type = "HAS_B")
    val b: MutableSet<B> = mutableSetOf<B>()
)

@RelationshipEntity(type = "HAS_B")
data class HasB @JvmOverloads constructor(
    @Id @GeneratedValue val id: Long? = null,
    @StartNode val start: A = A(),
    @EndNode val end: B = B()
)

@NodeEntity
data class B(
    @Id val id: String? = null,
    @Relationship(type = "HAS_C")
    val c: MutableSet<C> = mutableSetOf<C>()
)

...

[meistermeier]

You are not loading the HasB relationship entity but the B entity directly.

What worked for me:

@NodeEntity
data class A(
    @Id val id: String? = null,
    @Relationship(type = "HAS_B")
    var b: MutableSet<HasB> = mutableSetOf()
)

@RelationshipEntity(type = "HAS_B")
class HasB @JvmOverloads constructor(
    @Id @GeneratedValue val id: Long? = null,
    @StartNode val start: A = A(),
    @EndNode val end: B = B()
) {
    override fun toString(): String {
        return "HasB(id=$id, end=$end)"
    }
}

@NodeEntity
data class B(
    @Id val id: String? = null,
    @Relationship(type = "HAS_C")
    val c: MutableSet<C> = mutableSetOf()
)

@NodeEntity
data class C(
    @Id val id: String? = null
)

as you can see, I removed the data from data class B because the Has_B will create a class cycle that will call e.g. hashCode etc. in an endless loop (until it hits a stack overflow). There might be ways in Kotlin to keep it as a data class but ignore some fields. But my knowledge is limited about the Kotlin language specifics.

With a test

val c1 = C("C1")
val c2 = C("C2")
val b = B("b1", mutableSetOf(c1, c2))
val a = A("a1")
val hasB = HasB(null, a, b)
a.b = mutableSetOf(hasB)

var session = sessionFactory.openSession()
// I like my database empty before testing: session.purgeDatabase()

session.save(a)

// just to be sure to have a completely clean session state
session = sessionFactory.openSession()

val load = session.load(A::class.java, "a1", -1)

println(load)

I get A(id=a1, b=[HasB(id=6, end=B(id=b1, c=[C(id=C1), C(id=C2)]))])

[pc-dd]

Thank you for the response! This seems to be working.

Could you elaborate on why we should reference hasB instead of B? We were following the example here but this example has no RelationshipEntity. What is the underlying difference?

My guess is, it needs to trace from @NodeEntity data class A to @RelationshipEntity(type = "HAS_B") class HasB directly, but not what we thought to be true, i.e. trace from A to @Relationship(type = "HAS_B"), and then via the HAS_B trace to @RelationshipEntity(type = "HAS_B") data class HasB

[meistermeier]

First of all I somehow came to the conclusion that the @RelationshipEntity was the problem, sorry.
The explanation for this behaviour is that Neo4j-OGM finds the definition of HAS_B on this entity that also connects the types A and B. This brings the relationship entity being found and it eagerly wants to map to this....and fails.
I have to make up my mind about this. Currently I am in the mood to say this is a bug/unneeded limitation (if we don't mention this in the documentation). It was done before I maintained the project, so I have to be a little bit careful to not miss anything that led to the decision.

[pc-dd]

First of all I somehow came to the conclusion that the @RelationshipEntity was the problem, sorry. The explanation for this behaviour is that Neo4j-OGM finds the definition of HAS_B on this entity that also connects the types A and B. This brings the relationship entity being found and it eagerly wants to map to this....and fails. I have to make up my mind about this. Currently I am in the mood to say this is a bug/unneeded limitation (if we don't mention this in the documentation). It was done before I maintained the project, so I have to be a little bit careful to not miss anything that led to the decision.

Thanks! So I guess the key is "what is being annotated with @relationship"
Looks like in order for OGM to go from node entity A to relationship entity HasB, the thing being annotated with @relationship has to refer to the relationship entity itself, instead of node entity B (i.e. the node entity it connects A to). Is my understanding correct?

[meistermeier]

Yes, that is 100% correct. In your case this will solve the problem. If you don't need the properties on a relationship, you could also just remove the whole definition of the RelationshipEntity and OGM will map A->B.

It is just the definition for the RelationshipEntity named HAS_B in the metadata registry of OGM has precedence over the direct relationship definition in the NodeEntity. I have already discovered a little bit more why this happens and is explicitly defined in the mapping parts and currently testing a possible additional condition to avoid the mapping of the RelationshipEntity instead of the direct relationship.

[pc-dd]

Yes, that is 100% correct. In your case this will solve the problem. If you don't need the properties on a relationship, you could also just remove the whole definition of the RelationshipEntity and OGM will map A->B.

It is just the definition for the RelationshipEntity named HAS_B in the metadata registry of OGM has precedence over the direct relationship definition in the NodeEntity. I have already discovered a little bit more why this happens and is explicitly defined in the mapping parts and currently testing a possible additional condition to avoid the mapping of the RelationshipEntity instead of the direct relationship.

Got it, thanks! Closing this issue

[meistermeier]

There is now a fix for this in place in 3.2.41: https://github.com/neo4j/neo4j-ogm/releases/tag/v3.2.41

[pc-dd]

There is now a fix for this in place in 3.2.41: https://github.com/neo4j/neo4j-ogm/releases/tag/v3.2.41

Great, thanks! So now having the following would work?

@NodeEntity
data class A(
    @Id val id: String? = null,
    @Relationship(type = "HAS_B")
    val b: MutableSet<B> = mutableSetOf<B>()
)

(instead of var b: MutableSet<HasB> = mutableSetOf())

EDIT: looks like yes, just upgraded and tested. This is great

[meistermeier]

Thanks for the fast feedback on this. Faster than I could reply to the question.