Only one edge is going to be visualized if two nodes have multiple edges to each other

Moved from GitHub ratel/176

Posted by svenhartz:

How to reproduce

I created three nodes “Michael”, “Pawan” and “Leyla”. “Michael” is connected to “Leyla” with the "follows" and the "is_friend" edge. “Pawan” is connected to “Leyla” with the "follows" edge.

Observed behavior

I get the following JSON output with my query

    "data": {
    "name": [
      {
        "uid": "0x1",
        "name": "Michael",
        "follows": {
          "uid": "0x3",
          "name": "Leyla"
        },
        "is_friend": {
          "uid": "0x3",
          "name": "Leyla"
        }
      },
      {
        "uid": "0x2",
        "name": "Pawan",
        "follows": {
          "uid": "0x3",
          "name": "Leyla"
        }
      },
      {
        "uid": "0x3",
        "name": "Leyla"
      }
    ]
  },

The visualization looks like this:

So there is only one edge between “Michael” and “Leyla”.

Expected behavior

There should be two edges between Michael" and “Leyla”. One “follows” and one “is_friend” edge.

MichelDiz commented :

UPDATE:

The problem here is that the Ratel merges all components for a better view of the relationships between all these entities. It turns out that we don’t always want to see it that way, we would like to see objects (entities, vertices) even if duplicated with their own components independently.

This also affects the Shortest Path. To the point that it is not possible to view all paths found in the query in Graphs. For all the Nodes(entities, vertices) are merged. And information about Paths is lost(I mean, only in the view graph panel). Only possible to check it via inspection of the JSON response.

paulftw commented :

I think original bug – need for multiple edges is specific and unambiguous. Multiple connections between same two nodes should be visualized.

Second use case – separating nodes is debatable. We merge nodes into one based on the uid only. This is by design and this reflects the way data is stored in a graph. Lots of use cases depend on this. It sounds like a big and partly related feature request.

I’m going to interpret this bug as the need for multiple arrows, @MichelDiz feel free to file a separate FR with example use case to track the shortest path scenarios.

paulftw commented :