[ https://issues.apache.org/jira/browse/TINKERPOP-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052000#comment-16052000 ]
Daniel Kuppitz commented on TINKERPOP-1616: ------------------------------------------- I think we had this discussion on the list before. Or Slack? Dunno.. Anyway, I don't think we can say that one result is right and the other is wrong. Maybe {{LazyEvaluation}} should be a graph feature..? > Strengthen semantics around lazy iteration and graph modifications > ------------------------------------------------------------------ > > Key: TINKERPOP-1616 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1616 > Project: TinkerPop > Issue Type: Improvement > Components: structure > Affects Versions: 3.2.3 > Reporter: pieter martin > > The investigation started with the a bothE query where Sqlg returned > different results to TinkerGraph > {code} > @Test > public void testLazy1() { > final TinkerGraph graph = TinkerGraph.open(); > final Vertex a1 = graph.addVertex(T.label, "A"); > final Vertex b1 = graph.addVertex(T.label, "B"); > final Vertex c1 = graph.addVertex(T.label, "C"); > a1.addEdge("ab", b1); > a1.addEdge("ac", c1); > AtomicInteger count = new AtomicInteger(0); > graph.traversal().V(a1).bothE().forEachRemaining(edge -> { > a1.addEdge("ab", b1); > c1.addEdge("ac", a1); > count.getAndIncrement(); > }); > Assert.assertEquals(2, count.get()); > } > {code} > For this query TinkerGraph returns 2 and passes. > Sqlg however returns 3. The reason being that it lazily iterates the out() > first and then the in(). > The following gremlin is the same but using a union(out(), in()) instead of > bothE() > {code} > @Test > public void testLazy2() { > final TinkerGraph graph = TinkerGraph.open(); > final Vertex a1 = graph.addVertex(T.label, "A"); > final Vertex b1 = graph.addVertex(T.label, "B"); > final Vertex c1 = graph.addVertex(T.label, "C"); > a1.addEdge("ab", b1); > a1.addEdge("ac", c1); > AtomicInteger count = new AtomicInteger(0); > graph.traversal().V(a1).union(__.outE(), __.inE()).forEachRemaining(edge > -> { > a1.addEdge("ab", b1); > c1.addEdge("ac", a1); > count.getAndIncrement(); > }); > Assert.assertEquals(2, count.get()); > } > {code} > In this case TinkerGraph returns 4 and Sqlg 6 > TinkerGraph returns 4 as it first walks the 2 out edges and adds 2 in edges > which it sees when traversing the in(). > Sqlg return 6 as it lazier than TinkerGraph. > It first walks the "ac" out edge and adds in the 2 edges. > Then walks "ab" and gets 2 edges. The original and the one added previously. > It then walks "ac" in and gets 3 edges as 3 has been added so far. > All and all 6. > I am not sure whats the expected semantics. Sqlg is lazier than TinkerGraph > but not completely lazy either as it depends more on the meta data and number > of queries it needs to execute to walk a particular gremlin query. > I am somewhat of the opinion that without enforcing a eager iteration when > modifying a graph the semantics will be different for different implementors. > For Sqlg at least it will be hard for clients to predict the behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)