[
https://issues.apache.org/jira/browse/TINKERPOP-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907997#comment-16907997
]
stephen mallette commented on TINKERPOP-2282:
---------------------------------------------
I think that I would have guessed that what you're seeing is the expected
outcome given the design of the step. {{otherV()}} uses the path history of the
current traverser to determine which {{Vertex}} to get the other side of. By
continuing to traverse you place other possible {{Vertex}} instances on the
path that will get intercepted first. I'm not immediately sure what we would do
to fix this.
> 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: process
> Affects Versions: 3.4.3
> Reporter: Alex Baev
> Priority: Minor
>
> 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)
