[
https://issues.apache.org/jira/browse/TINKERPOP3-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14717307#comment-14717307
]
Matt Frantz commented on TINKERPOP3-779:
----------------------------------------
Sure, although {{coalesce}} was developed precisely to avoid the redundant
traversal shown in the {{choose}} example above.
The broader issue for any step accepting a traversal argument is this: Which
part of the state (object, path, sack, and side-effect) is visible to the child
traversal, and which part is retained in the parent afterwards? The more
rational we make those rules, the easier it will be to reason about the proper
usage of each step.
> coalesce should not forget path
> -------------------------------
>
> Key: TINKERPOP3-779
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-779
> Project: TinkerPop 3
> Issue Type: Bug
> Components: process
> Affects Versions: 3.0.0-incubating
> Reporter: Matt Frantz
> Assignee: Matt Frantz
>
> It seems like the path along whichever branch of the {{coalesce}} step should
> be preserved downstream. In 3.0.0, this is not the case:
> {noformat}
> gremlin> g.V().out().out().path()
> ==>[v[1], v[4], v[5]]
> ==>[v[1], v[4], v[3]]
> gremlin> g.V().coalesce(out().out()).path()
> ==>[v[1], v[5]]
> ==>[v[1], v[3]]
> {noformat}
> I would expect the output of the second statement to equal the first.
> Also, to be clear, the path should reflect whichever of the traversal
> arguments to {{coalesce}} were productive.
> {noformat}
> gremlin> g.V().out().out().path()
> ==>[v[1], v[4], v[5]]
> ==>[v[1], v[4], v[3]]
> gremlin> g.V().coalesce(out().out().out(), out().out()).path()
> ==>[v[1], v[5]]
> ==>[v[1], v[3]]
> {noformat}
> Again, I would expect the output of the second statement to equal the first.
> The path truncation behavior would be nice to preserve in the proposed
> {{sub}} step (TINKERPOP3-716).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
