Handling Layout Persistence with Bidirectional Edges

[glsp-bot]

We are currently working on integrating the bidirectional feature into the persistence of the edge's layout.

The problem with the bidirectional feature is, that we render only one of the eReferences as a GEdge. The GmodelFactory decides, based on a set of the eReference's hashCode, which object should be rendered and which one not. I have not found a better way to decide which eReference to take. This approach is similar to the Eclipse's Ecore Editor.

The problem now is that when the index object is newly created, and bidirecitonal Reference exists between Class A and B, sometimes the Reference A->B is used and sometime B->A. Now when the Edges are persisted on save, there might be two different Edges in the Enotation File.

```<elements xsi:type='enotation:Edge'>
    <semanticElement uri='//A/b'/>
    [...]
  </elements>
  <elements xsi:type='enotation:Edge'>
    <semanticElement uri='//B/a'/>
    [...]
  </elements>```

The question is how the edge can be reliably saved to the enotations. (And how we can assure to always use the same Edge.

The above mentioned features are already merged on the branch of our fork at review/sprintChristmas

original thread by Jonas Ebel

[tortmayr]

Hi, unfortunately I'm not able to reproduce this issue. For me bidirectional references are always reliably saved and there no unintended edges in the annotation file. I had a quick look at your code as well and theoretically this should work just fine and the first reference defined in the .ecore should be used. Maybe you have some instructions for me on how to reproduce this?

[glsp-bot]

[Jonas Ebel]

Hey Tobias I could recreate this with the following steps:

1. Create a Bidirectional Reference (Important: Use BiReference not BiContainment)

2. Save File.

3. Move the Edges around.

4. Save Again.

5. Close the File and open again.

6. Move the Edges again and Save.
   Now there could be two edges. It is not entirely reliable, as I cannot determine, which edge is the first given to the GModelFactory.

[glsp-bot]

[Jonas Ebel]

Hey @tortmayr have you been able to recreate this issue?

[tortmayr]

Unfortunately I'm still not able to recreate this. The only way I was able to achieve a (somewhat) similar result was by deleting a bireference and recreating it. However this is probably caused by eclipsesource/ecore-glsp#71

[tortmayr]

You could try to sort the collection of references in the GModelFactory before creating the corresponding GEdge.

[glsp-bot]

[simongraband]

Ok so we were able to solve this problem. The enotation always generated 2 elements, when the SourceClass was created after the TargetClass, since the ModelIndex finds the Nodes that are at the top of the enotation earlier than the ones at the bottom.

To fix this we made it so the edges are always created from the 'older' to the 'newer' Node.

```EReference opposite = createReference(targetEClass, sourceEclass, elementTypeId);
reference.setEOpposite(opposite);
opposite.setEOpposite(reference);

for(int i = 0; i< diagram.getElements().size();i++){
      if(diagram.getElements().get(i).equals(modelIndex.getNotation(sourceEclass).get())){
            break;
      }
      if(diagram.getElements().get(i).equals(modelIndex.getNotation(targetEClass).get())){
            reference = reference.getEOpposite();
            break;
      }
}```

Is this an acceptable solution or is this technically wrong because the edges were originally created the other way around by the user? Graphically this is not visible only in the enotation.

[tortmayr]

@eneufeld @camille-letavernier what do you think about this?

[CamilleLetavernier]

Stable UUIDs would provide more reliable/deterministic IDs and wouldn't require relying on positions or undeterministic values. Unfortunately, Ecore doesn't use UUIDs by default, and we can't enforce them either (Otherwise we would partially lose compatibility with external Ecore models).
I think that ideally, we would use the GLSP Notation model (Ecore GLSP currently uses its own simplified graph model, where most graphical elements - such as labels and edges - are derived from the semantic model)

[CamilleLetavernier]

Then we could have a much more explicitly relationship between Notation Elements (1 Edge + 2 Labels) and the corresponding EReferences (Source and Target, corresponding to each Label in the notation model)

[CamilleLetavernier]

And then positions/ids wouldn't matter anymore (Worst case would be: if the reference is renamed in the Ecore file outside of the Diagram Editor, the notation would reference an element that no longer exists; but we could clean it up & generate a new valid edge. We'd just lose serialized positions for that specific edge)

[CamilleLetavernier]

But... That's not the way it is, and this requires significant changes to the persisted enotation... So, I'm fine with position-based workarounds :)

[CamilleLetavernier]

They're certainly more stable/reliable than hashcodes and Ecore URI Fragments

[CamilleLetavernier]

(In terms of code though, that loop is quite expensive and can easily be optimized: moving
modelIndex.getNotation(source | target) outside of the loop (to compute them only once), and use a for (element : diagram.gelElements) rather than index-based iteration would be cleaner :) )