Ok, thanks.
Its tricky as it messes with the laziness and visibility of the queries.
Can really think of a solution though.
Cheers
Pieter
On 21/01/2017 21:14, Daniel Kuppitz wrote:
> Hi Pieter,
>
> forEachRemaining iterates over the result and hence I would expect the
> result to be 2. Otherwise you would / should end up with an endless loop.
> However, the same behavior is seen when you replace forEachRemaining with a
> sideEffect lambda step. Not sure what the expected behavior is / should be,
> but I think I prefer the way it's done now.
>
> Cheers,
> Daniel
>
>
> On Sat, Jan 21, 2017 at 7:30 PM, pieter-gmail <pieter.mar...@gmail.com>
> wrote:
>
>> 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
>>
>>
