[
https://issues.apache.org/jira/browse/TINKERPOP-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174347#comment-15174347
]
ASF GitHub Bot commented on TINKERPOP-1188:
-------------------------------------------
GitHub user okram opened a pull request:
https://github.com/apache/incubator-tinkerpop/pull/247
TINKERPOP-1188: Semantics of BarrierSteps in TraversalParent global
traversals is wrong.
https://issues.apache.org/jira/browse/TINKERPOP-1188
{{BranchSteps}} have a bug in them. Gremlin OLAP was correctly implementing
the semantics, but Gremlin OLTP was not. Branch step options are global
traversals and were acting like local traversals in OLTP. The fix to this bug
is "breaking" in that users would relied on this behavior will have to change
their traversals. However, its only for those traversals that have barriers in
their branches. For instance:
{code}
g.V.union(out,in) // okay
g.V.union(out.count(), in.count()) // breaking
{code}
If the user wants the same results for the second traversal above, they
need to do:
{code}
g.V.local(union(out.count(), in.count()))
{code}
**CHANGELOG**
```
* Fixed a semantic bug in `BranchStep` where barriers reacted locally.
(*breaking*)
```
**UPDATE DOCS**
```
BranchStep Bug Fix
^^^^^^^^^^^^^^^^^^^
For traversals that have barriers (e.g. `count()`, `max()`, `groupCount()`,
etc.) in a `branch()-step` (e.g. `union()` or `choose()`) , the traversal needs
to be updated. For instance, if a traversal is of the form
`g.V().union(out().count(),both().count())`, the behavior is now different.
There was a bug that has been fixed, but it changes the traversal result if the
user was relying on the buggy behavior. In order to effect the same behavior,
the traversal should be rewritten as
`g.V().local(union(out().count(),both().count()))`. Note that if a branch does
not have a barrier, then no changes are required. For instance,
`g.V().union(out(),both())` does not need to be updated.
```
`mvn clean install` passed. VOTE +1.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/incubator-tinkerpop TINKERPOP-1188
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-tinkerpop/pull/247.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #247
----
commit 14b54efb32000467b6949c12dd9422068297ac21
Author: Marko A. Rodriguez <okramma...@gmail.com>
Date: 2016-03-01T19:59:01Z
Fixed a bug in BranchStep (and its inheriting children -- union(),
choose(), etc.). Branch options are global traversals and should never reset()
on each insert. Moreover, they should fully pull from the source and not --
like a local traversal -- process one traverser at a time. If users were doing
union(sum,count), to get the same result they will need to do
local(union(sum,count)). Thus, its a breaking change -- but was a bug. This
also allowed us to remove one more ComputerVerificationStrategy filter. At this
point, OLAP is just like OLTP except for 'local star graph' stuff. Added a new
test case to UnionTest that demonstrates the local(union()) vs union() behavior.
commit 4b162f06475822a1d45390b566bb7e18ed76d90a
Author: Marko A. Rodriguez <okramma...@gmail.com>
Date: 2016-03-01T20:01:42Z
removed a restraint from ComputerVerificationStrategy. Forgot to update
test.
----
> Semantics of BarrierSteps in TraversalParent global traversals is wrong.
> ------------------------------------------------------------------------
>
> Key: TINKERPOP-1188
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1188
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.1.1-incubating
> Reporter: Marko A. Rodriguez
>
> Suppose the following traversal:
> {code}
> g.V.union(outE().count(), inE().count())
> {code}
> Given that {{count()}} is a {{ReducingBarrierStep}} and thus, continues to
> pull until there are no more results, you would expect the result set to be:
> {code}
> [6,6]
> {code}
> However, its actually this:
> {code}
> [3,0]
> [0,1]
> [0,3]
> [2,1]
> [0,1]
> [1,0]
> {code}
> That is, for each traverser into {{union()}}, the {{count()}} is calculated.
> In OLAP, the result is {{[6,6]}} as expected.
> What should we do?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
