[jira] [Commented] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848603#comment-15848603 ] 

Marko A. Rodriguez commented on TINKERPOP-1619:
-----------------------------------------------

The simple solution to this problem is to treat the {{optional()}} traversal as a local child and, thus, reset prior to each new {{addStart()}}. This means that {{dedup())}} in an optional-traversal would be reset for each incoming traverser. This will solve that fact that we are currently treating {{optional()}} as a "pseudo" local traversal that has both local and global properties.

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