Spring Data not populating Relationships with ID [DATAGRAPH-1444]

[spring-projects-issues]

Marcos Stival opened DATAGRAPH-1444 and commented

After upgrading to Spring Boot 2.4.0 (so using SDN 6.0.1) I got some problems.

There's no @RelationshipEntity anymore so I guess in my code I should change it to @RelationshipProperties.

 

After searching the documentation I can't figure how to make it return the id property of a relationship. +Before the version upgrade, every relationship property was returned correctly, now it doesn't.+

I tried to add a @Property annotation to the id field, but an Exception was raised by Spring.

The id field is annotated with @Id and @GeneratedValue

 
 
 
 

---

Affects: 6.0.1 (2020.0.1)

[spring-projects-issues]

Gerrit Meier commented

A relationship with properties (@RelationshipProperties) is intended to be not an entity anymore.
It is only part of an aggregate and should be loaded through the aggregate root and not via direct access.
If you need to get the id for any reason, you should be fine with using the Neo4jClient (or its reactive counterpart), that will join an ongoing Spring transaction if wanted.

May I ask why you need the identifier?

[spring-projects-issues]

Marcos Stival commented

Sure Gerrit Meier. In our project the frontend uses Linkurious' Ogma library which needs a unique identifier to place entities and relationships on its canvas and ensure there aren't any duplicates.
 

By using the new Neo4JClient you mean to instead of using Spring's derived queries (findBy....) I should build queries by hand using the client?

My business case requires a hierarchical structure between entities, which is represented by a relationship downwards.

Actually, I have to traverse it recursively starting at the aggregate root and then accessing each parentOf to create the response I will be returning from the service.

// API Response example
{
    "code": "ABC1",
    "name": "Client A",
    "parentOf": [
        {
            "id": "XYZ987", // Since SDN 6.0.1, "id": "null"
            "child": {
                "code": "CDE2",
                "name": "Client B",
                "parentOf": [ ... ]
            }
        }
    ]
}

[spring-projects-issues]

Gerrit Meier commented

I wonder if the example, you have posted matches the behaviour you are facing and assume that the id was a numeric value before, right?
So they were always "random" because they were based on the internal id mechanism of Neo4j.
Wouldn't it make sense in this case to keep them "random"?
So doing sth. like private final String id = UUID.randomUUID().toString() should do the same job as they were loaded before.
Maybe I think just to simple here and you could tell me why, besides the uniqueness of the entity in Ogma, the id is needed

[spring-projects-issues]

Marcos Stival commented

Wow, I haven't thought about that. Let me check with the frontend team then I will get back to you. 

Thanks Gerrit Meier !

EDIT: 

Hey Gerrit Meier, I've just talked with the frontend team.

They told me that in principle, there shouldn't be any problem but after thinking a bit we realized that in the case the same edge is returned with a different UUID it could be drawn over as the Ogma library will differentiate them based on their ID. 

An example query that could return the same edge with different id could be an expandNode endpoint (given a node ID, return its neighbours). If we call this endpoint twice the UUID generated for the relationships will be different (as they are not backed by the database).

I'm gonna make a quick PoC locally then come back with the results

[spring-projects-issues]

Michael Simons commented

Hey, you can of course introduce an actual property.

match () - [p:WHATEVER_THE_RELATION_SHIP_IS_NAMED] -> () 
set p.id = randomUUID() return p

this will add a graph property named id. This can happily coexists with the internal id (which can always be retrieved via codeid(node or relationship)code.

On the domain model you would annotate it with code``@Property``code but not with @Id, as we won't allow the later.

This way, you would have stable identifiers and not have any additional load on the client by calling all those new uuids (Related: http://www.wasteaguid.info ;) )

[michael-simons]

Related to #2118 Id properties will be filled very soon.

[mrksph]

Nice! @michael-simons

[meistermeier]

Is this solved for you with the latest version?

[meistermeier]

Closing this because there were no new input and the issue seems to be solved in general.