[
https://issues.apache.org/jira/browse/TINKERPOP-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1616.
---
Resolution: Won't Do
In looking at this today, I don't think we need to add a graph feature for
this. I think that if a graph provider has slightly different semantics than
TinkerGraph, then that's ok. It is just up to the graph provider to ensure that
their users are aware of their differing behavior (likely through
documentation). In cases where TinkerPop is enforcing some semantics via the
test suite, I think it's also ok for the graph provider to {{OptOut}} of the
test as necessary for their system. By providing a "reason" to that {{OptOut}}
they document their position on why they have differing semantics. Graph
features are useful in cases where they can block out whole swaths of tests but
in this case I don't think we have that scenario here. {{OptOut}} would be the
better approach if it applies at all.
I'm closing this as there's not been any further discussion here in recent
months, but if closing was premature, let's continue the discussion.
> 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)
