[ 
https://issues.apache.org/jira/browse/TINKERPOP-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette reassigned TINKERPOP-1616:
-------------------------------------------

    Assignee: stephen mallette

> 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
>            Assignee: stephen mallette
>            Priority: Major
>
> 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
(v7.6.3#76005)

Reply via email to