[
https://issues.apache.org/jira/browse/TINKERPOP-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847131#comment-15847131
]
Ted Wilmes commented on TINKERPOP-1619:
---------------------------------------
Ok, that makes sense. I was wondering if when I bumped the worker count to 4
the duplicate edges were no longer being processed by the same worker and the
dedup wasn't global. Kuppitz had a variation of this query as a test case for
TINKERPOP-1597 so I'll go ahead and close that one out now.
> TinkerGraphComputer worker count affects OptionalStep query results
> -------------------------------------------------------------------
>
> Key: TINKERPOP-1619
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.3.0
> Reporter: Ted Wilmes
>
> I found that when I bump the worker count up to 4 on my local box, the dedup
> nested in the optional appears to not be handled correctly.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.withComputer(Computer.compute().workers(3)).V(1,
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> ==>v[2]
> gremlin> g.withComputer(Computer.compute().workers(4)).V(1,
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
