Closed oxisto closed 3 months ago
This is indeed interesting if this should really happen. From what I can see in our test suite this should not be a problem.
Could you provide also the information what Node
is in your example?
It would be also helpful to see the test code that sets up the entities and persist them, to get the full picture.
This is indeed interesting if this should really happen. From what I can see in our test suite this should not be a problem. Could you provide also the information what
Node
is in your example? It would be also helpful to see the test code that sets up the entities and persist them, to get the full picture.
Hi! Node
ist just a normal base class. I will try to distill a running example from our code base during the day today. The code base is open-source, but it might be too complex to just simply run.
This would be very helpful, thanks.
This would be very helpful, thanks.
I managed to put it together here: https://github.com/oxisto/kotlin-ogm-test Note that this example is a bit more complex (and contains some generics), but it also fails without the generics.
From the given example (and sorry that I missed this in the examples above), I can see that this is expected behaviour in Neo4j-OGM. It fails with the NPE because it cannot find the matching definition for the "unknown" relationship type.
Without a type / value in the @RelationshipEntity
annotation it will fall back to UPPER_SNAKECASE for the naming.
The types need to be in sync.
While writing and confirming this in code, I figured out that this is partial true: It is just plain upper case. Don't know why this changed. (I am happy to create a new issue for this)
Also see this in the reference documentation: https://neo4j.com/docs/ogm-manual/current/reference/#reference:annotating-entities:relationship-entity
From the given example (and sorry that I missed this in the examples above), I can see that this is expected behaviour in Neo4j-OGM. It fails with the NPE because it cannot find the matching definition for the "unknown" relationship type. Without a type / value in the
@RelationshipEntity
annotation it will fall back to UPPER_SNAKECASE for the naming. The types need to be in sync. While writing and confirming this in code, I figured out that this is partial true: It is just plain upper case. Don't know why this changed. (I am happy to create a new issue for this)Also see this in the reference documentation: https://neo4j.com/docs/ogm-manual/current/reference/#reference:annotating-entities:relationship-entity
That only seems to be partially true because the relationshipType
variable is correctly set to BODY
if I debug it. Yes you are correct that it fails with an NPE because it cannot find a relationship entity class for this using the metadata/classdata lookup. However, the mapper seems to be "intelligent" enough to see that AstEdge
is in fact a relationship entity and if you add an additional null check, things continue normally (see my PR). It seems the only reason the added look-up is here, is to check whether the returned class (which happens to be null) is abstract. Well if its null its never abstract so the normal control flow could continue.
is to check whether the returned class (which happens to be null) is abstract
Unfortunately being null
as in "I don't know this entity" differs to plain false
. What if the class is abstract but not correctly mapped?
Additionally, there are other places in the code that are trying to resolve the information of a particular class via Metadata#classInfo
and are relying on those information.
This is a little bit of a complicated issue, but it seems I encounter a somewhat weird behaviour, if one uses
RelationshipEntity
objects for single-node relationships.Consider the following (Kotlin) code:
(the real example code is a bit more complex with generics, but the issue still seems to persist with this small example)
When trying to persist this I get the following error:
If I change the
@Relationship
name toASTEDGE
(matching the relationship entity class in uppercase), the graph persists without problems. Persisting a list of such entities withBODY
also works.Expected Behavior
I would expect that the above sample works.
Current Behavior
See stack-trace