Hi,
I need to clarify the expected semantics of gremlin's lazy iteration
semantics.
The following gremlin is what highlighted it.
```
@Test
public void testLazy() {
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);
//a1.addEdge("ac", c1);
count.getAndIncrement();
});
Assert.assertEquals(2, count.get());
}
```
On TinkerGraph the count is always 2.
On Sqlg's Postgresql dialect the `bothE` first traverses the 'ac' edges
adds in a 'ab' edge and then traverses the 'ab' edges and ends up with a
count of 3.
On Sqlg's HSQLDB and H2 dialects the `bothE` first traverses the 'ab'
edges adds in a 'ab' edge then traverses the 'ac' edges and ends up with
a count of 2.
So for Sqlg the added edge will be seen by subsequent traversals due to
the lazy nature but the order affects the result.
TinkerGraph seems to get both 'ab' and 'ac' edges upfront and does not
subsequently see the added edge. A bit like it has a hidden barrier step
before the `forEachRemaining`.
What is the expected semantics in this situation?
Is a traversal that traverses an element that has been modified earlier
in the same traversal suppose to see the change?
Thanks
Pieter
