[
https://issues.apache.org/jira/browse/TINKERPOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842430#comment-16842430
]
Daniel Choi commented on TINKERPOP-2220:
----------------------------------------
Thanks Daniel, I see what you're getting at. Although I feel like if dedup()'s
meaning is different in the context of repeat, maybe it would've been better to
separate it out as an explicit argument to do sort of "distinct" graph search
(only process each node once). repeat().distinct(true) or something like that.
It just seems weird that repeat() is normally meant to repeat the inner
traversal verbatim, except if it's a dedup() then it's not (evidenced by
special case handling of dedup() inside repeat() in unroll strategy).
I realize repeat() is usually used to implement graph search like BFS in
gremlin and there are strong merits to having a mechanism to reduce the
frontier based on a visited set, and that dedup() is being used for this use
case. But it seems to start to muddy the semantics of repeat() and maybe it's
better to have repeat() as verbatim repetition of the inner traversal while
making separate dedicated steps for graph search (with various search related
options: bfs, dfs, bi-directional, etc.)?
> Dedup inside Repeat Produces 0 results
> --------------------------------------
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.3.0
> Reporter: Rahul Chander
> Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0
> results, while dedup twice produced the correct 6.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
