[jira] [Comment Edited] (TINKERPOP-1429) Branch step inside where step misbehaves

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

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

Marko A. Rodriguez edited comment on TINKERPOP-1429 at 9/15/16 2:22 PM:
------------------------------------------------------------------------

I don't quite understand the toy graph example from @dkuppitz, but what I do notice is that a reducing barrier step is being used inside a local child traversal. {{where}} compiles to {{TraversalFilterStep}} which resets its internal "local" child traversal after each incoming traverser is processed. Thus, for each incoming traverser, the a new {{count()}} is calculated which, at most will be 1.

Here is a simple example on the MODERN graph.

{code}
// GOOD
gremlin> g.V().branch(label()).option("software",count()).option("person",count())
==>2
==>4
// GOOD
gremlin> g.V().branch(label()).option("software",count().is(2)).option("person",count().is(4))
==>2
==>4
// UNEXPECTED
gremlin> g.V().where(branch(label()).option("software",count().is(2)).option("person",count().is(4)))
gremlin>
{code}

Now watch this:

{code}
gremlin> g.V().where(branch(label()).option("software",count().is(1)).option("person",count().is(4)))
==>v[3]
==>v[5]
{code}

For that local traversal, there is 1 software! Thus, {{v[3]}} and {{v[5]}} go through the filter.

I know this is confusing to users. I don't know how to make clear that distinction between global and local processing, where *global* means, process the entire stream and *local* means process the stream created by a single input traverser. Both are important concepts and are needed, but it just entails that sometimes a nested traversal is "per traverser" (local) and sometimes "per traversers" (global). ......

Does this clear up the ISSUE or is there still something deeper I'm missing?



was (Author: okram):
I don't quite understand the toy graph example from @dkuppitz, but what I do notice is that a reducing barrier step is being used inside a local child option. {{where}} compiles to {{TraversalFilterStep}} which resets its internal "local" child traversal after each incoming traverser is processed. Thus, for each incoming traverser, the a new {{count()}} is calculated which, at most will be 1.

Here is a simple example on the MODERN graph.

{code}
// GOOD
gremlin> g.V().branch(label()).option("software",count()).option("person",count())
==>2
==>4
// GOOD
gremlin> g.V().branch(label()).option("software",count().is(2)).option("person",count().is(4))
==>2
==>4
// UNEXPECTED
gremlin> g.V().where(branch(label()).option("software",count().is(2)).option("person",count().is(4)))
gremlin>
{code}

Now watch this:

{code}
gremlin> g.V().where(branch(label()).option("software",count().is(1)).option("person",count().is(4)))
==>v[3]
==>v[5]
{code}

For that local traversal, there is 1 software! Thus, {{v[3]}} and {{v[5]}} go through the filter.

I know this is confusing to users. I don't know how to make clear that distinction between global and local processing, where *global* means, process the entire stream and *local* means process the stream created by a single input traverser. Both are important concepts and are needed, but it just entails that sometimes a nested traversal is "per traverser" (local) and sometimes "per traversers" (global). ......

Does this clear up the ISSUE or is there still something deeper I'm missing?


> Branch step inside where step misbehaves
> ----------------------------------------
>
>                 Key: TINKERPOP-1429
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1429
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: process
>    Affects Versions: 3.0.1-incubating
>            Reporter: Jordi Chacon
>
> https://groups.google.com/forum/#!topic/gremlin-users/0LSvVRtjERg



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)