@RelationshipProperties support for @Id @GeneratedValue private UUID id;

[MaurizioCasciano]

The @RelationshipProperties only supports

@Id
@GeneratedValue
private Long id;

Can this be extended to also support the UUID type as it is for @Node annotated classes?

@Id
@GeneratedValue
private UUID id;

[michael-simons]

Thanks, @MaurizioCasciano that is an excellent topic to talk to. Right now, not yet. This is atm strictly the internal marker we need to keep the rel properties internally identifiable without creating proxies for them. We need to work in this area anyhow as Neo4j 5 deprecated support for id() instead for elementId().

Pinging @meistermeier about this too

[meistermeier]

I would be interested in the use-case, you are trying to cover by assigning custom ids? I am just trying to figure out how this can benefit SDN.
As Michael described it correctly, the internal id is a helper for us to not override existing relationships on save/update that might contain unknown (to SDN) properties.

[MaurizioCasciano]

Hi @meistermeier, the use-case I am trying to cover is the modeling of unique relationships having an external identifier (String | UUID) without having to maintain multiple IDs in the DB.

We could add a property to the relationship (e.g. private UUID uuid;) but then we will have also private Long id; creating confusion. Furthermore, the uuid field would also require a unique constraint to be generated.

Considering as an example a list of software licensed to a list of people, there is the need to model the license as a relationship using the existing identifier.

(s:Software{id:"9149843d-aef1-4795-8dbd-481ca365c3c6"})-[:License{id:"a915af52-961a-4fc0-a5d6-0f51b601e92e", expiration:"2022-11-01T11:24:58Z"}]->(p:Person{id:"ca33c0b9-e61c-4be3-9105-b21db0a68e2d"})

[meistermeier]

Sorry for losing track of this issue. Unfortunately, I can only repeat ourselves and tell you that it is not this easy to add an alternative id type (like we have in the entities) to RelationshipProperties. A huge parts of the handling of those definitions relies on knowing the internal id (query creation, for example).
But I see the benefits it could bring for a cleaner definition of the entity itself. I leave this issue open as an enhancement idea.

[pabloaguilarm]

Hi @meistermeier , related with this, I am having some issues because, as @michael-simons said, with the change from id() to elementId(), it appears a lot of warnings when a relation is saved. I have been able to update nodes from long id to string, but RelationshipProperties fail.

[meistermeier]

Could you tell us which version of SDN you are running? If it is SDN 7.1.0 (with Spring Boot 3.1.0) there was a changed introduce that handles elementId() as first class ids. But you have to tell the underlying Cypher-DSL to use the NEO4J_5 dialect. This will be added to the documentation with the next patch release. Also, there will be a change added that mitigates the situation if the dialect is not explicitly set.
See also #2729 (comment) for reference to the needed Cypher-DSL configuration bean.

[pabloaguilarm]

We are using Spring Boot 2.7.12. Does this version have the changes or Spring Boot 2.7.12 has SDN 6.3.12?

[pabloaguilarm]

Even with the Cypher-DSL configuration bean, it appears this error for the properties of a relationship is missing a property for the generated, internal ID (@Id @GeneratedValue Long id) which is needed for safely updating properties.. And @meistermeier, for what I am seeing, it appears the same error if I just change the id of the target node of relationship and leave the relation id as long.