I'd say TinkerGraph demonstrates the expected behavior - I guess we don't
have a test that enforces that?
On Sat, Jan 21, 2017 at 3:23 PM, pieter-gmail <pieter.mar...@gmail.com>
wrote:
> 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
> >>
> >>
>
>
