[TinkerPop 3] Discrepancy between Vertex.addEdge() and GraphTraversal<S,E>.addE()

[Vladyslav Kosulin]

While Traversal makes use of Direction, Vertex supports only creation of outgoing edge. IMHO, it would be nice if Vertex.addEdge() allowed Direction as parameter. There are many use cases where bi-directional edges should be created, and single method as part of TP3 API makes the code much cleaner, IMHO. Otherwise, I have to create my own wrapper.

[Marko Rodriguez]

Hello,

If you do a.addEdge("knows",b) and you want the inverse, just do b.addEdge("knows",a). Meaning, you already have both vertices (a/b) so whichever one you want to have the outgoing edge, make that the one that calls addE().

HTH,

Marko.

http://markorodriguez.com

On May 26, 2015, at 9:16 AM, Vladyslav Kosulin <vkos...@gmail.com> wrote:

While Traversal makes use of Direction, Vertex supports only creation of outgoing edge. IMHO, it would be nice if Vertex.addEdge() allowed Direction as parameter. There are many use cases where bi-directional edges should be created, and single method as part of TP3 API makes the code much cleaner, IMHO. Otherwise, I have to create my own wrapper.

--
You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/0cf82bc9-cfdc-4855-8372-29b5be487b69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marko Rodriguez]

Hello,

The problem with this comes with T.id. We could make it so that you could do this, but if you specify a T.id, then it would be ignored. However, that is awkward as some addEdge() will keep the T.id and others will not. Your utility seems sufficient for graphs that do not support userSuppliedIds and you want all the properties on both edges to be duplicated.

Marko.

http://markorodriguez.com

On May 26, 2015, at 12:37 PM, Vladyslav Kosulin <vkos...@gmail.com> wrote:

I understand this. What I mean is that instead of calling 

a.addEdge(b); b.addEdge(a);

I'd prefer to make a single call

a.addEdge(Direction. BOTH, b).

Right now I use an utility static method 

Edge[] addEdge(DIRECTION, label, v1, v2, ...),

but would love to see this as atomic operation and part of core Vertex API.

And because some relationships are truly bi-directional in their nature, it would be even cooler if you allowed creation of essentially bi-directional edges as single entity, which would be returned by both inE(), outE(). And when I add a property to this edge once, it is present in both in() and out() calls, etc.

But I understand the complications, and I am sure this was discussed somewhere in depth already...

To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/9638e120-16fe-474f-9ad2-bd187702a373%40googlegroups.com.

[Vladyslav Kosulin]

I understand this. What I mean is that instead of calling 

a.addEdge(b); b.addEdge(a);

I'd prefer to make a single call

a.addEdge(Direction. BOTH, b).

Right now I use an utility static method 

Edge[] addEdge(DIRECTION, label, v1, v2, ...),

but would love to see this as atomic operation and part of core Vertex API.

And because some relationships are truly bi-directional in their nature, it would be even cooler if you allowed creation of essentially bi-directional edges as single entity, which would be returned by both inE(), outE(). And when I add a property to this edge once, it is present in both in() and out() calls, etc.

But I understand the complications, and I am sure this was discussed somewhere in depth already...

I am just facing a dilemma: either create duplicates for billions of edges to represent their bi-directional nature (which means bigger database and possible inconsistency if edges are mutable), or write traversals for specific labels which include both inE() and outE() (I favor this approach for now, but it is also not as pretty as truly bi-directional edges).

On Tuesday, May 26, 2015 at 11:25:39 AM UTC-4, Marko A. Rodriguez wrote:

[Daniel Kuppitz]

Hi Vladyslav,

seriously, I don't see any advantage in your approach. Why would you create 2 edges instead of one? It requires

• more disk space
  
• more memory during traversals
• synchronization mechanisms (if you remove / update one edge, you need to take the other into account as well)
• one more write operation then necessary for every CUD operation

Being able to use just .out("label") or .in("label") instead of .both("label") in your traversals doesn't seem to be an advantage at all (to me).

Cheers,

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/9ed7409d-cb64-4cc6-a79b-9a50f63e9047%40googlegroups.com.

[Vladyslav Kosulin]

Well, this is exactly why I favor a single edge approach (see my last sentence in previous reply).

The issue here is that when I need to read both edge parameters and linked vertex parameters, then when I use bothE(), I can't just use inVertex()/outVertex() on traversal result, because I do not know the current edge direction. Therefore, I have to iterate over 2 separate traversals inE() and outE().

[Daniel Kuppitz]

Oh, I see, but you can use .otherV().

Cheers,

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/4f3d2aef-f1ab-4c20-838f-b51f502466b7%40googlegroups.com.