[GitHub] [tinkerpop] dkuppitz opened pull request #997: TINKERPOP-2095 GroupStep looks for irrelevant barrier steps
https://issues.apache.org/jira/browse/TINKERPOP-2095
This PR fixes a bug that somehow managed to stay unnoticed for years.
Prior this PR we got this:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
```
Now we get this:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
==>[ripple:32,lop:96]
```
The fix was made for both - `GroupStep` and `GroupSideEffectStep`. I also had
to fix `ComputerVerificationStrategy`; it didn't detect that
`select('p').values('age')` is leaving the star-graph.
Without the `ComputerVerificationStrategy` fix:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
==>[ripple:0,lop:0]
```
With the `ComputerVerificationStrategy` fix:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
Local traversals may not traverse past the local star-graph on GraphComputer:
[SelectOneStep(last,p), PropertiesStep([age],value), SumGlobalStep]
```
`docker/build.sh -t -i -n` passed.
VOTE +1
[ Full content available at: https://github.com/apache/tinkerpop/pull/997 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Commented] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690026#comment-16690026
]
ASF GitHub Bot commented on TINKERPOP-2095:
---
dkuppitz opened a new pull request #997: TINKERPOP-2095 GroupStep looks for
irrelevant barrier steps
URL: https://github.com/apache/tinkerpop/pull/997
https://issues.apache.org/jira/browse/TINKERPOP-2095
This PR fixes a bug that somehow managed to stay unnoticed for years.
Prior this PR we got this:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
```
Now we get this:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
==>[ripple:32,lop:96]
```
The fix was made for both - `GroupStep` and `GroupSideEffectStep`. I also
had to fix `ComputerVerificationStrategy`; it didn't detect that
`select('p').values('age')` is leaving the star-graph.
Without the `ComputerVerificationStrategy` fix:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
==>[ripple:0,lop:0]
```
With the `ComputerVerificationStrategy` fix:
```
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
Local traversals may not traverse past the local star-graph on
GraphComputer: [SelectOneStep(last,p), PropertiesStep([age],value),
SumGlobalStep]
```
`docker/build.sh -t -i -n` passed.
VOTE +1
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> GroupStep looks for irrelevant barrier steps
>
>
> Key: TINKERPOP-2095
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {{GroupStep}} looks for a {{Barrier}} step to determine the reducing
> bi-operator. This is wrong and I'm really surprised that this has never been
> spotted before.
> {noformat}
> gremlin>
> g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
> java.lang.Long cannot be cast to
> org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> In the query above the first barrier step is a {{NoOpBarrier}} step (added by
> {{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
> What we really want to do is look for the first barrier step that is not a
> {{LocalBarrier}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-2095:
--
Description:
{{GroupStep}} looks for a {{Barrier}} step to determine the reducing
bi-operator. This is wrong and I'm really surprised that this has never been
spotted before.
{noformat}
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
In the query above the first barrier step is a {{NoOpBarrier}} step (added by
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
What we really want to do is look for the first barrier step that is not a
{{LocalBarrier}} step.
was:
{{GroupStep}} looks for {{Barrier}} step to determine the reducing bi-operator.
This is wrong and I'm really surprised that this has never been spotted before.
{noformat}
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
In the query above the first barrier step is a {{NoOpBarrier}} step (added by
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
What we really want to do is look for the first reducing barrier step.
> GroupStep looks for irrelevant barrier steps
>
>
> Key: TINKERPOP-2095
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.3.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {{GroupStep}} looks for a {{Barrier}} step to determine the reducing
> bi-operator. This is wrong and I'm really surprised that this has never been
> spotted before.
> {noformat}
> gremlin>
> g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
> java.lang.Long cannot be cast to
> org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> In the query above the first barrier step is a {{NoOpBarrier}} step (added by
> {{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
> What we really want to do is look for the first barrier step that is not a
> {{LocalBarrier}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps
Daniel Kuppitz created TINKERPOP-2095:
-
Summary: GroupStep looks for irrelevant barrier steps
Key: TINKERPOP-2095
URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
{{GroupStep}} looks for {{Barrier}} step to determine the reducing bi-operator.
This is wrong and I'm really surprised that this has never been spotted before.
{noformat}
gremlin>
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}
In the query above the first barrier step is a {{NoOpBarrier}} step (added by
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator.
What we really want to do is look for the first reducing barrier step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2094) Gremlin Driver Cluster Builder serializer method does not use mimeType as suggested
Lyndon Armitage created TINKERPOP-2094:
--
Summary: Gremlin Driver Cluster Builder serializer method does not
use mimeType as suggested
Key: TINKERPOP-2094
URL: https://issues.apache.org/jira/browse/TINKERPOP-2094
Project: TinkerPop
Issue Type: Bug
Components: driver
Affects Versions: 3.3.4
Environment: Linux
Java 8
Kotlin
Reporter: Lyndon Armitage
Whilst struggling with getting serialization working as expected during testing
I noticed that the following method does not work as expected:
org.apache.tinkerpop.gremlin.driver.Cluster.Builder#serializer(java.lang.String)
Specifically this code:
{code:java}
/**
* Set the {@link MessageSerializer} to use given its MIME type. Note that
setting this value this way
* will not allow specific configuration of the serializer itself. If specific
configuration is required
* please use {@link #serializer(MessageSerializer)}.
*/
public Builder serializer(final String mimeType) {
serializer = Serializers.valueOf(mimeType).simpleInstance();
return this;
}
{code}
It suggests that the string argument being used should be a MIME type like
"application/json" but due to how the method Serializers.valueOf() works it in
fact checks the enum name value.
See the class org.apache.tinkerpop.gremlin.driver.ser.Serializers for some
context.
The valueOf method checks against the name of the enum which for the
"appliction/json" example would actually be "GRAPHSON".
There is a property called value and function called getValue() that were
probably the intended targets for matching against.
A solution for this would be to simply check against each enum instance's value
property via the getter method mentioned earlier. Something like this:
{code:java}
public Builder serializer(final String mimeType) {
for (Serializers serializer : Serializers.values()) {
if (serializer.getValue().equals(mimeType)) {
this.serializer = serializer.simpleInstance();
break;
}
}
return this;
}
{code}
You could extract this (or the matching part of it) into a static method on the
Serializers enum type if such a matching pattern is common.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
