[jira] [Reopened] (TINKERPOP-1616) Strengthen semantics around lazy iteration and graph modifications

["stephen mallette (JIRA)" <ji...@apache.org>]

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

stephen mallette reopened TINKERPOP-1616:
-----------------------------------------

I feel like I was a bit too hasty here.....I just came across TINKERPOP-1685 and I feel like a Graph Feature would be helpful there. Perhaps we should address this issue as well. [~pietermartin] were there tests you actually opted out of for this issue? or did you just uncover it through other means?

> 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)