[
https://issues.apache.org/jira/browse/TINKERPOP-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17855682#comment-17855682
]
ASF GitHub Bot commented on TINKERPOP-3080:
-------------------------------------------
rdtr commented on code in PR #2616:
URL: https://github.com/apache/tinkerpop/pull/2616#discussion_r1643189640
##########
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/verification/ComputerVerificationStrategy.java:
##########
@@ -80,6 +78,13 @@ public void apply(final Traversal.Admin<?, ?> traversal) {
if (UNSUPPORTED_STEPS.stream().filter(c ->
c.isAssignableFrom(step.getClass())).findFirst().isPresent())
throw new VerificationException("The following step is
currently not supported on GraphComputer: " + step, traversal);
+
+ if (step instanceof SideEffectCapable) {
+ final BinaryOperator<?> sideEffectOperator =
traversal.getSideEffects().getReducer(((SideEffectCapable<?, ?>)
step).getSideEffectKey());
+ if (sideEffectOperator instanceof Operator && (!((Operator)
sideEffectOperator).isCommutative())) {
+ throw new VerificationException("The following step has an
SideEffect operator " + sideEffectOperator + " which is currently not supported
on GraphComputer: " + step, traversal);
+ }
+ }
Review Comment:
Without this, in GraphComputer test I see that the unit tests I added
failed. It seems GraphComputer works like map-reduce so when we have input like
`1,2,3,4,5,6` for example, they are split into small chunk and operator is
applied.
So for example, let's say we have 3 hosts and data are split like `1, 6`,
`2, 4`, and `3, 5`. With `ADD` it is fine because on each host the result would
be `7`, `6`, and `8`. They are further summed up to 7 + 6 + 8 = 21 so the
result is consistent.
However, for `MINUS`, a result in each host would be `-5`, `-2`, and `-2`
then -5 - (-2) - (-2) = -1. This is not what we want because what we expect to
happen is 1 - 2 - 3 - 4 - 5 - 6.
I believe that we can still make it to work in distributed env with some
tweak, but Stephen agreed to disable it for now.
> AggregateStep can support all Operators predefined in TinkerPop
> ---------------------------------------------------------------
>
> Key: TINKERPOP-3080
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3080
> Project: TinkerPop
> Issue Type: Improvement
> Components: language, process
> Reporter: Norio Akagi
> Priority: Major
> Fix For: 3.7.3
>
>
> Currently, {{AggreteGlobalStep}} and {{AggreteLocalStep}} only support addAll
> and assign as Operator. This is because they use BulkSet to apply to
> Operator. Only addAll and assign can work with BulkSet, so for other
> operators it results in a type casting failure.
> They can be more flexible to work with any operators depending on what is set
> by {{{}withSideEffect(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
