Alex Baev created TINKERPOP-2282:
------------------------------------
Summary: EdgeOtherVertexStep sometimes uses the wrong vertex to
calculate otherV()
Key: TINKERPOP-2282
URL: https://issues.apache.org/jira/browse/TINKERPOP-2282
Project: TinkerPop
Issue Type: Bug
Components: structure
Affects Versions: 3.4.3
Reporter: Alex Baev
EdgeOtherVertexStep always looks for the last vertex in the path and uses that
vertex to calculate the "other" vertex (see the
[code|https://github.com/apache/tinkerpop/blob/3.4.3/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/EdgeOtherVertexStep.java#L47]).
This implementation works most of the time, but it produces unexpected results
if a different vertex is injected into the path between the right vertex and
the call to otherV(). For example:
{code:java}
gremlin> G = TinkerFactory.createModern()
gremlin> g = G.traversal()
gremlin> g.V().has('name', 'marko').outE().as('e').V().has('name',
'peter').select('e').otherV().values('name')
==>marko
==>marko
==>marko
{code}
In the example above, otherV() returns marko because the implementation applies
otherV() to V().has('name', 'peter') instead of V().has('name', 'marko')
Another example:
{code:java}
gremlin> g.V().has('name',
'marko').outE().as('e').otherV().select('e').otherV().path()
==>[v[1],e[9][1-created->3],v[3],e[9][1-created->3],v[1]]
==>[v[1],e[7][1-knows->2],v[2],e[7][1-knows->2],v[1]]
==>[v[1],e[8][1-knows->4],v[4],e[8][1-knows->4],v[1]]
{code}
The first .otherV() returns the right vertex, but the second one always returns
v[1]. This happens because the second otherV() is applied to the result
returned by the first otherV(), which seems incorrect.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
