Migrating SDN 4.0 to SDN 6.0: Difficulties mapping @RelationshipEntity and @StartNode, @EndNode

[gviteri]

Hi all,
I am having some trouble trying to migrate from SDN 4.1 to 6.0.x. We heavily use @RelationshipEntity with @StartNode and @EndNode, from the OGM. I have seem in the documentation and other posts that the way to go is @RelationshipProterties and @TargetNode.

I am going to put some code here and any help, advice will be extremely welcome!

OGM Implementation

@RelationshipEntity(type = "hasCandidate")
public class HasCandidate implements Comparable<HasCandidate> {
    @Id private Long id;
    @StartNode private EntitySet entitySet;
    @EndNode private PhysicalEntity physicalEntity;
    private Integer stoichiometry = 1;
    private int order;
    // getter and setters

Now, the class that takes the Relationship, still using the OGM implementation

@NodeEntity
public class CandidateSet extends EntitySet {
    @Relationship(type = "hasCandidate")
    private SortedSet<HasCandidate> hasCandidate;
    // any other code
}

Our modelling comes from a legacy code and can't be changed. So, a CandidateSet extends EntitySet and an EntitySet extends PhysicalEntity.

Now the way I am thinking with the new approach @RelationshipProperties

@RelationshipProperties
public class HasCandidate implements Comparable<HasCandidate> {
    @Id private Long id;
    @TargetNode private PhysicalEntity physicalEntity;
    private Integer stoichiometry = 1;
    private int order;

... and the class that uses HasCandidate relationship

@Node
public class CandidateSet extends EntitySet {

    @Relationship(type = "hasCandidate")
    private SortedSet<HasCandidate> hasCandidate;

and also the @TargetNode class has an attribute for this Relationship in the Physical Entity class.

@Node
public class PhysicalEntity extends DatabaseObject {
    ...
    @Relationship(type = "hasComponent", direction = Relationship.Direction.INCOMING)
    private SortedSet<HasCandidate> hasCandidate;

I am not so sure if this is the correct way, taking into account that PhysicalEntity is the @TargetNode and it also the superclass for CandidateSet and EntitySet ( as @StartNode in the previous implementation.

According to the example I need to add Relationship.Direction.INCOMING

Questions:

1. Is the code above correct ?
2. How do I set the name as I was doing before ?@RelationshipEntity(type = "hasCandidate")

Unfortunately, due to all the updates and refactoring I am doing at the moment, I can't test it, but I was wondering if this is correct and make sense.

Thanks everyone, Cheers.

[gerrit_meier · Accepted solution]

There are a few adjustments left to do:

1. The INCOMING definition is not needed and would also wrong, if I understand your use-case correctly, because in that case a PhysicalEntity would have an incoming relationship to a PhysicalEntity and not the CandidateSet.
2. If you want to mimic the previous definition of the HasCandidate, you could also pull up the relationship definition from CandidateSet to EntitySet. In this case every derived class from EntitySet would have the relationship.

For the second question: the name/type is already defined correctly in the CandidateSet via the @Relationship definition. There is no need to define the type twice in SDN 6.

[gviteri]

Thanks for your prompt reply!

1. Right, biologically speaking, a PhysicalEntity (PE) is a "roughly" a protein and we can combine them, put them together. In certain cases, a PE has to behave like a CandidateSet which contains a collection that stores all the PEs that are the candidates.

Note: In the datamodel PhysicalEntity is the superclass for CandidateSet and EntitySet

Ex. We have 7  PEs Nodes ( a,b,c,d,e,f,g)
For PE-a the hasCandidate list contains ( PE-b, PE-g)
For PE-f the hasCandidate list contains ( PE-b, PE-d, PE-e)

That's how we have the data for these relationships.

because in that case a PhysicalEntity would have an incoming relationship to a PhysicalEntity and not the CandidateSet .
Not sure if I understood this as a CandidateSet.hasCandidates attribute will target PhysicalEntity as a node for the Relationship, am I seeing it correctly based on the new approach ?

2. OK. Yes, I got that! In our use case a CandidateSet has candidates (as one relationship) and the EntitySet which is another an superclass has members (as a relationship).
   We are following the data-model of our legacy application , which is like that,

Great. Perfect.
Thanks

[gviteri]

Hey @gerrit.meier

I ran the BatchInserter (we convert a MySQL db into graph) and looks like the Relationship is working. I haven't test on the SDN repository yet but I've been doing some complex cypher that we use and they are producing the same results as before.

Thanks for your help.