[ 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)