When using optional, it is expected that the result of the step will be what was traversed to within the optional, or what the traversal was at before the optional.
Consider this setup:
a = g.addV('A').next();
b = g.addV('B').next();
c = g.addV('C').next();
d = g.addV('D').next();
a.addEdge('a2b', b);
a.addEdge('a2c', c);
When using optional, it is expected that the result of the step will be what was traversed to within the optional, or what the traversal was at before the optional.
Consider this setup:
a = g.addV('A').next(); b = g.addV('B').next(); c = g.addV('C').next(); d = g.addV('D').next(); a.addEdge('a2b', b); a.addEdge('a2c', c);
Executing this traversal:
g.V().hasLabel('A').as('a').optional(out('a2b')).select('a').optional(out('a2c').out('c2d')).path();
I'd expect to get the A vertex, the B vertex, and then the A vertex again as the out.out in the second optional does not complete.
Within TinkerGraph, that is what happens:
==>[v[17],v[18],v[17]]
Using Sqlg 2.0.1, nothing is returned.
If the a2c edge is removed, then Sqlg does return the right/same thing as TinkerGraph:
==>[v[public.A:::8],v[public.B:::6],v[public.A:::8]]
So it seems there is a bug in optional when there are multiple steps.