[
https://issues.apache.org/jira/browse/TINKERPOP3-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14716943#comment-14716943
]
Matt Frantz commented on TINKERPOP3-779:
----------------------------------------
Should we leave this ticket open as a use case for the TINKERPOP3-693? This
was a request to support a specific kind of traversal, so if we agree we want
to support this use case, we should capture that as unit tests (which are
already written as cited above), even if the implementation is handled by
another issue.
> 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)
