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