Generated objects onSave are not considered as already processed.

[Wayne-P]

So looking for a little clarification here on a possible issue.

As first referenced by https://community.neo4j.com/t/kotlin-neo4j-graph-saving/36378/1

Kotlin 1.4.31
Spring Framework Boot 2.4.4
Desktop 4.2.4
also see GitHub - https://github.com/Wayne-P/graph/tree/master

So we have three classes imaginatively labelled A, B & C

@Node ("NODE_A")
data class A constructor(
    @Id @GeneratedValue val id: Long? = null, val aName: String, @Relationship(type = "A_TO_B_REL") val b: B, @Relationship(type = "A_TO_C_REL") val c: C
)
@Node ("NODE_B")
data class B constructor(
    @Id @GeneratedValue val id: Long? = null, val bName:String, @Relationship(type = "B_TO_C_REL") val cList: List<C>
)
@Node("NODE_C")
data class C constructor(
    @Id @GeneratedValue val id: Long? = null, val cName: String
)

So, roughly,
A has a B and a C.
B has a list of C .
So far, so good.

The application code ...

@Transactional
@SpringBootApplication
class GraphApplication {
    @Bean
    fun init(aRepository: ARepository, bRepository: BRepository, cRepository: CRepository): CommandLineRunner {
        return CommandLineRunner {
            val c1 = C(cName = "c1")
            val c2 = C(cName = "c2")
            val b1 = B(bName = "b1", cList = listOf(c1, c2))
            val a1 = A(aName = "a1", b = b1, c = c1)

            aRepository.deleteAll()
            bRepository.deleteAll()
            cRepository.deleteAll()

            aRepository.save<A>(a1)
        }
    }
}

fun main(args: Array<String>) {
    runApplication<GraphApplication>(*args)
}

Now curiously, repeated efforts to execute this code give different results.
Sometimes, an IllegalStateExcexception from the save attempt of

java.lang.IllegalStateException: Failed to execute CommandLineRunner
	at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:809) ~[spring-boot-2.4.4.jar:2.4.4]
	at org.springframework.boot.SpringApplication.callRunners(SpringApplication.java:790) ~[spring-boot-2.4.4.jar:2.4.4]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:333) ~[spring-boot-2.4.4.jar:2.4.4]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1313) ~[spring-boot-2.4.4.jar:2.4.4]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1302) ~[spring-boot-2.4.4.jar:2.4.4]
	at aoni.graph.GraphApplicationKt.main(GraphApplication.kt:39) ~[main/:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:na]
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:566) ~[na:na]
	at org.springframework.boot.devtools.restart.RestartLauncher.run(RestartLauncher.java:49) ~[spring-boot-devtools-2.4.4.jar:2.4.4]
Caused by: java.util.NoSuchElementException: No value present
	at java.base/java.util.Optional.get(Optional.java:148) ~[na:na]

Other times, the code runs without exception to produce two c1 s with different ids.
I would have expected to see a graph with just one c1 ,as opposed to a tree.

I appreciate that work has been done in
https://github.com/spring-projects/spring-data-neo4j/issues/2148
to ensure that ids of subcomponents are correctly returned in response to a save, but will this work lead to one c1 being created here ?

Many thanks for considering this.

[meistermeier]

Thanks for reporting this.
There is now a issue/gh-2223 branch in place that should produce a 6.0.9-GH-2223-SNAPSHOT version in a few minutes.
It would be good to get your feedback on this. It looks, at least to me, that the problems, either exception or too much nodes, is gone with this. The change is still a WIP (only imperative, needs some cleaning) but I wanted to get you into the feedback loop as fast as possible.
To use this, you would have to add

repositories {
  mavenCentral()
  maven { url = uri("https://repo.spring.io/milestone") }
  maven { url = uri("https://repo.spring.io/snapshot") }
}

to your repositories and

implementation("org.springframework.data:spring-data-neo4j:6.0.9-GH-2223-SNAPSHOT")

[Wayne-P]

Thanks, I have run this 7 times now and on each occasion, it provided me with better results !

[Wayne-P]

I can feed this snapshot into a more challenging graph this evening and will let you know tonight whether that works.

[meistermeier]

Thanks you very much for the fast feedback.
It might be still rough on the edges but yes, go ahead and stress it ;)

[Wayne-P]

Okay, I gave this a slightly more extreme test and (a) the saves did not throw an exception and (b) the resulting node displays looked fine in the neo4j desktop application.
I assume that the saves are still not expected to return all of the hydrated ids, as of this snapshot ?

[meistermeier]

(yet another) great feedback, thanks.
Yes, the id hydration is not yet finished for this fix but at least now I am sure that the direction is the right one and I have not misinterpreted the initial cause for the bug.