Closed spring-projects-issues closed 3 years ago
kibantony commented
Edited the description to reflect M4 passes the test, RC-1 fails
Gerrit Meier commented
Thanks for reporting this. This was indeed a bug in the mapping internals that got introduced by another change. We are currently working on the fix and it will be solved with the next patch
kibantony commented
Thanks for the quick fix guys. I just verified that with SDN 6.0.2 this now works in the test project and in my real project. (y)
BreadAndRoses95 commented
I'm still encountering some error while mapping to more than one level with version 6.0.2. It's not always the case, but sometimes SDN cannot retrieve my entities in the tree of relationships.
It happens, for example when I have the following pattern: A->B->C->D. Saving A and retrieving A is working, but not always. And retrieving all Bs is never working. The error states that C could not be constructed because D was null.
D has a Composite propertiy with a custom converter (don't know if this can help or not)
Gerrit Meier commented
Could you update your example to give us more insights?
BreadAndRoses95 commented
Hello,
Here's a minimal project with my issue https://we.tl/t-n0Wsbif8S6 The sepcific test is called
Update of a graph view will not remove the removed entities
,
Thanks a lot for your reactivity !
Gerrit Meier commented
I can see that there is a problem but this is not due to the loading and retrieving but the null
value for the provderInstance
in ProviderData
that Kotlin does not like.
@Relationship(type = ProviderDataOutgoingRelationships.USES_BY_DEFAULT, direction = Relationship.Direction.OUTGOING)
val providerInstance: ProviderInstance?
Helps here and it is working
BreadAndRoses95 commented
Yes but in this case, the provider instance is set to null, and not to its actual value even after the repository call ends, which does not match the graph. (The provider instance exists and is related to the ProviderData if you look at the saved Graph View)
I don't understand why this would be necessary for this field only, and it looks to me as a loading and retrieving bug, no?
Gerrit Meier commented
I thought that there is nothing set, but you are right, there is a providerInstance
but we are not querying for it
BreadAndRoses95 commented
This is what I thought when I tried to debug around the test in the spring data neo4j code, it looks like it's stopping the path traversal at some level, but could not figure out why
Gerrit Meier commented
Could you try it with version 6.0.2-DATAGRAPH-1433-SNAPSHOT
?
It works at least on my machine ;)
BreadAndRoses95 commented
-I cannot retrieve this version maven says :/-
It's ok now, and working in this version, thanks ! Do you know when the 6.0.2 will be released please?
Gerrit Meier commented
Tomorrow ;) https://calendar.spring.io/
BreadAndRoses95 commented
Hello,
I still get errors when mapping with DSN 6.0.2. (I have several nodes that are connected to the same entity with @CompositProperties
),
Have a look at the test called
Update of a graph view will not remove the removed entities
The generated path is extremely long, and ends up by throwing an error
Caused by: java.lang.NullPointerException: Parameter specified as non-null is null: method com.devel.test.testspringdataneo4j.domain.model.system.SystemImplementation.<init>, parameter system
Do you know how to handle this?
kibantony opened DATAGRAPH-1431 and commented
As recently as Spring Boot 2.4.0-M4 (not sure which SDN version that is? 6.0.0?), using a ReactiveNeo4jRepository it was possible to save and retrieve (via simple calls such as findById, using no custom queries) a three level nested class/node hierarchy, but in the release version of Spring Boot 2.4.0 (SDN 6.0.1?) this no longer works. The third level of the hierarchy is not retrieved.
Please refer to the example project here: TestNeo4j
If you run the test WidgetRepositoryTest in this project you'll notice it fails. If you change the Spring Boot version in the Gradle file to 2.4.0-M4, the test will succeed.
Given entity classes such as these (edited down for brevity):
The following test fails because findById returns the Widget and its list of WidgetEvents, but the list of EventValues in each WidgetEvent is null.
Again this works fine in SB-M4 and appears to be broken in the release. I can find no mention in the documentation or release notes of the expected behavior here.
Here's a section of the logs with relevant queries:
Affects: 6.0.1 (2020.0.1)
Backported to: 6.0.2 (2020.0.2)