[jira] [Commented] (TINKERPOP-1682) by-modulator optimization strategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408911#comment-16408911
]
ASF GitHub Bot commented on TINKERPOP-1682:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/621
That's weird, this test works for me consistently.
This is the test code:
```
found = 0;
for (final String line : traversal.explain().prettyPrint(160).split("]\n"))
{ // need to split cause of word wrap
if (line.contains("IncidentToAdjacentStrategy") &&
line.contains("[VertexStep(IN,vertex)"))
found++;
if (line.contains("IncidentToAdjacentStrategy") &&
line.contains("[VertexStep(OUT,vertex)"))
found++;
if (line.contains("AdjacentToIncidentStrategy") &&
line.contains("[VertexStep(BOTH,edge)"))
found++;
if (line.contains("CountStrategy") &&
line.contains("RangeGlobalStep(0,3)"))
found++;
}
assertEquals(4, found);
```
And this is the result of `prettyPrint()`:
```
Traversal Explanation
=
Original Traversal[VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
ConnectiveStrategy [D] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
RepeatUnrollStrategy[O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
ByModulatorOptimizationStrategy [O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
MatchPredicateStrategy [O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
FilterRankingStrategy [O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
InlineFilterStrategy[O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
IncidentToAdjacentStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,vertex),
CountGlobalStep, Is
Step(gt(2))])],[FoldStep])]
AdjacentToIncidentStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
CountGlobalStep, IsSt
ep(gt(2))])],[FoldStep])]
CountStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
PathRetractionStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
LazyBarrierStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
ProfileStrategy [F] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
StandardVerificationStrategy[V] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
[GitHub] tinkerpop issue #621: TINKERPOP-1682 by-modulator optimization strategy
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/621
That's weird, this test works for me consistently.
This is the test code:
```
found = 0;
for (final String line : traversal.explain().prettyPrint(160).split("]\n"))
{ // need to split cause of word wrap
if (line.contains("IncidentToAdjacentStrategy") &&
line.contains("[VertexStep(IN,vertex)"))
found++;
if (line.contains("IncidentToAdjacentStrategy") &&
line.contains("[VertexStep(OUT,vertex)"))
found++;
if (line.contains("AdjacentToIncidentStrategy") &&
line.contains("[VertexStep(BOTH,edge)"))
found++;
if (line.contains("CountStrategy") &&
line.contains("RangeGlobalStep(0,3)"))
found++;
}
assertEquals(4, found);
```
And this is the result of `prettyPrint()`:
```
Traversal Explanation
=
Original Traversal[VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
ConnectiveStrategy [D] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
RepeatUnrollStrategy[O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
ByModulatorOptimizationStrategy [O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
MatchPredicateStrategy [O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
FilterRankingStrategy [O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
InlineFilterStrategy[O] [VertexStep(OUT,edge),
EdgeVertexStep(IN), GroupStep([VertexStep(IN,edge), EdgeVertexStep(OUT),
GroupCountStep([VertexS
tep(BOTH,vertex), CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
IncidentToAdjacentStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,vertex),
CountGlobalStep, Is
Step(gt(2))])],[FoldStep])]
AdjacentToIncidentStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
CountGlobalStep, IsSt
ep(gt(2))])],[FoldStep])]
CountStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
PathRetractionStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
LazyBarrierStrategy [O] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
ProfileStrategy [F] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
StandardVerificationStrategy[V] [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
CountGlobalStep,
IsStep(gt(2))])],[FoldStep])]
Final Traversal [VertexStep(OUT,vertex),
GroupStep([VertexStep(IN,vertex), GroupCountStep([VertexStep(BOTH,edge),
RangeGlobalStep(0,3),
[jira] [Commented] (TINKERPOP-1910) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
[ https://issues.apache.org/jira/browse/TINKERPOP-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408621#comment-16408621 ] Ashwini Singh commented on TINKERPOP-1910: -- My bad. Thanks > Gremlin.Net does not have complete object model as compared to other client > drivers and unable to de-serialize properties for vertex/edge graphSON. > - > > Key: TINKERPOP-1910 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1910 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.3.1 >Reporter: Ashwini Singh >Priority: Major > > Looks like the object model for Gremlin.Net client driver is not as par with > Java driver. We cannot deserialize a GraphSON response to tinkerpop object > completely. For example, Gremlin.Net object model cannot deserialize > properties from a graphSON response object (vertex/edges). Currently, we only > deserialize id and label field from a vertex/edge graphSON. > > So, to desterilize the object model, users have to write a custom > deserialization code and create the object. The current de-serializers (for > vertex/edge) will strip off details like properties. > > I am filing it as a bug but it could fall into improvement as well. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1682) by-modulator optimization strategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408608#comment-16408608
]
ASF GitHub Bot commented on TINKERPOP-1682:
---
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/621
```
docker/build.sh -i -t -n
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
4.187 s <<< FAILURE! - in
org.apache.tinkerpop.gremlin.process.traversal.util.TraversalExplanationTest
[ERROR]
shouldApplyStrategiesCorrectly(org.apache.tinkerpop.gremlin.process.traversal.util.TraversalExplanationTest)
Time elapsed: 0.048 s <<< FAILURE!
java.lang.AssertionError: expected:<4> but was:<3>
at
org.apache.tinkerpop.gremlin.process.traversal.util.TraversalExplanationTest.shouldApplyStrategiesCorrectly(TraversalExplanationTest.java:136)
```
> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The can be a significant difference in performance depending on whether you
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 12.13758.03
> VertexStep(OUT,vertex) 6
> 6 1.345 6.43
> VertexStep(IN,vertex) 12
> 12 0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12
> 12 6.57031.42
> IdStep 36
> 36 0.452
> >TOTAL -
> - 20.916-
> gremlin> g.V().out().in().path().by(id).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 0.87611.54
> VertexStep(OUT,vertex) 6
> 6 0.714 9.40
> VertexStep(IN,vertex) 12
> 12 3.29943.43
> PathStep([id])12
> 12 2.70635.63
> >TOTAL -
> - 7.596-
> {noformat}
> We should have a strategy that rewrites these simple patterns. This affects
> {{id()}}, {{label()}}, {{key()}}, {{value()}}, but also
> {{by(values("name"))}}, which can be rewritten as {{by("name")}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #621: TINKERPOP-1682 by-modulator optimization strategy
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/621 ``` docker/build.sh -i -t -n [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.187 s <<< FAILURE! - in org.apache.tinkerpop.gremlin.process.traversal.util.TraversalExplanationTest [ERROR] shouldApplyStrategiesCorrectly(org.apache.tinkerpop.gremlin.process.traversal.util.TraversalExplanationTest) Time elapsed: 0.048 s <<< FAILURE! java.lang.AssertionError: expected:<4> but was:<3> at org.apache.tinkerpop.gremlin.process.traversal.util.TraversalExplanationTest.shouldApplyStrategiesCorrectly(TraversalExplanationTest.java:136) ``` ---
[jira] [Updated] (TINKERPOP-1928) Gremlin .Net driver not able produce partial results.
[ https://issues.apache.org/jira/browse/TINKERPOP-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwini Singh updated TINKERPOP-1928: - Summary: Gremlin .Net driver not able produce partial results. (was: Gremlin .Net drivers not able parse partial results.) > Gremlin .Net driver not able produce partial results. > -- > > Key: TINKERPOP-1928 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1928 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Reporter: Ashwini Singh >Priority: Major > > Gremlin.Net accumulates partial results and returns consolidated result. Java > driver does have the capability to stream partial result. > > We should try to achieve consistent behavior for other drivers like python, > nodejs etc as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-1928) Gremlin .Net drivers not able parse partial results.
Ashwini Singh created TINKERPOP-1928: Summary: Gremlin .Net drivers not able parse partial results. Key: TINKERPOP-1928 URL: https://issues.apache.org/jira/browse/TINKERPOP-1928 Project: TinkerPop Issue Type: Improvement Components: dotnet Reporter: Ashwini Singh Gremlin.Net accumulates partial results and returns consolidated result. Java driver does have the capability to stream partial result. We should try to achieve consistent behavior for other drivers like python, nodejs etc as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1682) by-modulator optimization strategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408588#comment-16408588
]
ASF GitHub Bot commented on TINKERPOP-1682:
---
Github user dkuppitz commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/621#discussion_r176239480
--- Diff: CHANGELOG.asciidoc ---
@@ -110,7 +112,6 @@ This release also includes changes from
<>.
* Removed access to previously deprecated `CoreGremlinPlugin#INSTANCE`
field.
* `gremlin.sh` and `gremln.bat` no longer support the option to pass a
script as an argument for execution mode without using the `-i` option.
* Graphite and Ganglia are no longer packaged with the Gremlin Server
distribution.
-* `TransactionException` is no longer a class of `AbstractTransaction` and
it extends `RuntimeException`.
--- End diff --
That was unintentional, not show how/why/when that happened. I will add it
back.
> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The can be a significant difference in performance depending on whether you
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 12.13758.03
> VertexStep(OUT,vertex) 6
> 6 1.345 6.43
> VertexStep(IN,vertex) 12
> 12 0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12
> 12 6.57031.42
> IdStep 36
> 36 0.452
> >TOTAL -
> - 20.916-
> gremlin> g.V().out().in().path().by(id).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 0.87611.54
> VertexStep(OUT,vertex) 6
> 6 0.714 9.40
> VertexStep(IN,vertex) 12
> 12 3.29943.43
> PathStep([id])12
> 12 2.70635.63
> >TOTAL -
> - 7.596-
> {noformat}
> We should have a strategy that rewrites these simple patterns. This affects
> {{id()}}, {{label()}}, {{key()}}, {{value()}}, but also
> {{by(values("name"))}}, which can be rewritten as {{by("name")}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #621: TINKERPOP-1682 by-modulator optimization strate...
Github user dkuppitz commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/621#discussion_r176239480 --- Diff: CHANGELOG.asciidoc --- @@ -110,7 +112,6 @@ This release also includes changes from <>. * Removed access to previously deprecated `CoreGremlinPlugin#INSTANCE` field. * `gremlin.sh` and `gremln.bat` no longer support the option to pass a script as an argument for execution mode without using the `-i` option. * Graphite and Ganglia are no longer packaged with the Gremlin Server distribution. -* `TransactionException` is no longer a class of `AbstractTransaction` and it extends `RuntimeException`. --- End diff -- That was unintentional, not show how/why/when that happened. I will add it back. ---
[jira] [Commented] (TINKERPOP-1682) by-modulator optimization strategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408585#comment-16408585
]
ASF GitHub Bot commented on TINKERPOP-1682:
---
Github user dkuppitz commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/621#discussion_r176238971
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/ByModulatorOptimizationStrategy.java
---
@@ -0,0 +1,110 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package
org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization;
+
+import org.apache.tinkerpop.gremlin.process.traversal.Step;
+import org.apache.tinkerpop.gremlin.process.traversal.Traversal;
+import org.apache.tinkerpop.gremlin.process.traversal.TraversalStrategy;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.ElementValueTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.IdentityTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.TokenTraversal;
+import org.apache.tinkerpop.gremlin.process.traversal.step.ByModulating;
+import org.apache.tinkerpop.gremlin.process.traversal.step.TraversalParent;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.IdStep;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.LabelStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.IdentityStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.strategy.AbstractTraversalStrategy;
+import org.apache.tinkerpop.gremlin.structure.PropertyType;
+import org.apache.tinkerpop.gremlin.structure.T;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+/**
+ * This strategy looks for standard traversals in by-modulators and
replaces them with more optimized traversals
+ * (e.g. {@code TokenTraversal}) if possible.
+ *
+ *
+ * @author Daniel Kuppitz (http://gremlin.guru)
+ * @example
+ * __.path().by(id())// is replaced by __.path().by(id)
+ * __.dedup().by(label())// is replaced by __.dedup().by(label)
+ * __.group().by(key()) // is replaced by __.group().by(key)
+ * __.group().by(value())// is replaced by __.group().by(value)
--- End diff --
Oh right, I will remove them from the examples or add a note. key and value
actually depend on TINKERPOP-1689, which is still an open issue.
> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The can be a significant difference in performance depending on whether you
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 12.13758.03
> VertexStep(OUT,vertex) 6
> 6 1.345 6.43
> VertexStep(IN,vertex) 12
> 12 0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12
> 12 6.57031.42
> IdStep
[GitHub] tinkerpop pull request #621: TINKERPOP-1682 by-modulator optimization strate...
Github user dkuppitz commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/621#discussion_r176238971
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/ByModulatorOptimizationStrategy.java
---
@@ -0,0 +1,110 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package
org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization;
+
+import org.apache.tinkerpop.gremlin.process.traversal.Step;
+import org.apache.tinkerpop.gremlin.process.traversal.Traversal;
+import org.apache.tinkerpop.gremlin.process.traversal.TraversalStrategy;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.ElementValueTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.IdentityTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.TokenTraversal;
+import org.apache.tinkerpop.gremlin.process.traversal.step.ByModulating;
+import org.apache.tinkerpop.gremlin.process.traversal.step.TraversalParent;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.IdStep;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.LabelStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.IdentityStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.strategy.AbstractTraversalStrategy;
+import org.apache.tinkerpop.gremlin.structure.PropertyType;
+import org.apache.tinkerpop.gremlin.structure.T;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+/**
+ * This strategy looks for standard traversals in by-modulators and
replaces them with more optimized traversals
+ * (e.g. {@code TokenTraversal}) if possible.
+ *
+ *
+ * @author Daniel Kuppitz (http://gremlin.guru)
+ * @example
+ * __.path().by(id())// is replaced by __.path().by(id)
+ * __.dedup().by(label())// is replaced by __.dedup().by(label)
+ * __.group().by(key()) // is replaced by __.group().by(key)
+ * __.group().by(value())// is replaced by __.group().by(value)
--- End diff --
Oh right, I will remove them from the examples or add a note. key and value
actually depend on TINKERPOP-1689, which is still an open issue.
---
[jira] [Commented] (TINKERPOP-1682) by-modulator optimization strategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408579#comment-16408579
]
ASF GitHub Bot commented on TINKERPOP-1682:
---
Github user robertdale commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/621#discussion_r176237542
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/ByModulatorOptimizationStrategy.java
---
@@ -0,0 +1,110 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package
org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization;
+
+import org.apache.tinkerpop.gremlin.process.traversal.Step;
+import org.apache.tinkerpop.gremlin.process.traversal.Traversal;
+import org.apache.tinkerpop.gremlin.process.traversal.TraversalStrategy;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.ElementValueTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.IdentityTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.TokenTraversal;
+import org.apache.tinkerpop.gremlin.process.traversal.step.ByModulating;
+import org.apache.tinkerpop.gremlin.process.traversal.step.TraversalParent;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.IdStep;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.LabelStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.IdentityStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.strategy.AbstractTraversalStrategy;
+import org.apache.tinkerpop.gremlin.structure.PropertyType;
+import org.apache.tinkerpop.gremlin.structure.T;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+/**
+ * This strategy looks for standard traversals in by-modulators and
replaces them with more optimized traversals
+ * (e.g. {@code TokenTraversal}) if possible.
+ *
+ *
+ * @author Daniel Kuppitz (http://gremlin.guru)
+ * @example
+ * __.path().by(id())// is replaced by __.path().by(id)
+ * __.dedup().by(label())// is replaced by __.dedup().by(label)
+ * __.group().by(key()) // is replaced by __.group().by(key)
+ * __.group().by(value())// is replaced by __.group().by(value)
--- End diff --
Are key()/value() replaced? Looks like they are commented out below.
> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The can be a significant difference in performance depending on whether you
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 12.13758.03
> VertexStep(OUT,vertex) 6
> 6 1.345 6.43
> VertexStep(IN,vertex) 12
> 12 0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12
> 12 6.57031.42
> IdStep 36
> 36 0.452
>
[GitHub] tinkerpop pull request #621: TINKERPOP-1682 by-modulator optimization strate...
Github user robertdale commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/621#discussion_r176237542
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/ByModulatorOptimizationStrategy.java
---
@@ -0,0 +1,110 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package
org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization;
+
+import org.apache.tinkerpop.gremlin.process.traversal.Step;
+import org.apache.tinkerpop.gremlin.process.traversal.Traversal;
+import org.apache.tinkerpop.gremlin.process.traversal.TraversalStrategy;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.ElementValueTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.IdentityTraversal;
+import
org.apache.tinkerpop.gremlin.process.traversal.lambda.TokenTraversal;
+import org.apache.tinkerpop.gremlin.process.traversal.step.ByModulating;
+import org.apache.tinkerpop.gremlin.process.traversal.step.TraversalParent;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.IdStep;
+import org.apache.tinkerpop.gremlin.process.traversal.step.map.LabelStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.IdentityStep;
+import
org.apache.tinkerpop.gremlin.process.traversal.strategy.AbstractTraversalStrategy;
+import org.apache.tinkerpop.gremlin.structure.PropertyType;
+import org.apache.tinkerpop.gremlin.structure.T;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+/**
+ * This strategy looks for standard traversals in by-modulators and
replaces them with more optimized traversals
+ * (e.g. {@code TokenTraversal}) if possible.
+ *
+ *
+ * @author Daniel Kuppitz (http://gremlin.guru)
+ * @example
+ * __.path().by(id())// is replaced by __.path().by(id)
+ * __.dedup().by(label())// is replaced by __.dedup().by(label)
+ * __.group().by(key()) // is replaced by __.group().by(key)
+ * __.group().by(value())// is replaced by __.group().by(value)
--- End diff --
Are key()/value() replaced? Looks like they are commented out below.
---
[jira] [Commented] (TINKERPOP-1682) by-modulator optimization strategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408575#comment-16408575
]
ASF GitHub Bot commented on TINKERPOP-1682:
---
Github user robertdale commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/621#discussion_r176236647
--- Diff: CHANGELOG.asciidoc ---
@@ -110,7 +112,6 @@ This release also includes changes from
<>.
* Removed access to previously deprecated `CoreGremlinPlugin#INSTANCE`
field.
* `gremlin.sh` and `gremln.bat` no longer support the option to pass a
script as an argument for execution mode without using the `-i` option.
* Graphite and Ganglia are no longer packaged with the Gremlin Server
distribution.
-* `TransactionException` is no longer a class of `AbstractTransaction` and
it extends `RuntimeException`.
--- End diff --
Why does this get removed from an earlier version?
> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The can be a significant difference in performance depending on whether you
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 12.13758.03
> VertexStep(OUT,vertex) 6
> 6 1.345 6.43
> VertexStep(IN,vertex) 12
> 12 0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12
> 12 6.57031.42
> IdStep 36
> 36 0.452
> >TOTAL -
> - 20.916-
> gremlin> g.V().out().in().path().by(id).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 0.87611.54
> VertexStep(OUT,vertex) 6
> 6 0.714 9.40
> VertexStep(IN,vertex) 12
> 12 3.29943.43
> PathStep([id])12
> 12 2.70635.63
> >TOTAL -
> - 7.596-
> {noformat}
> We should have a strategy that rewrites these simple patterns. This affects
> {{id()}}, {{label()}}, {{key()}}, {{value()}}, but also
> {{by(values("name"))}}, which can be rewritten as {{by("name")}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #621: TINKERPOP-1682 by-modulator optimization strate...
Github user robertdale commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/621#discussion_r176236647 --- Diff: CHANGELOG.asciidoc --- @@ -110,7 +112,6 @@ This release also includes changes from <>. * Removed access to previously deprecated `CoreGremlinPlugin#INSTANCE` field. * `gremlin.sh` and `gremln.bat` no longer support the option to pass a script as an argument for execution mode without using the `-i` option. * Graphite and Ganglia are no longer packaged with the Gremlin Server distribution. -* `TransactionException` is no longer a class of `AbstractTransaction` and it extends `RuntimeException`. --- End diff -- Why does this get removed from an earlier version? ---
[jira] [Commented] (TINKERPOP-1682) by-modulator optimization strategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408554#comment-16408554
]
ASF GitHub Bot commented on TINKERPOP-1682:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/621
Rebased, issues addressed and conflicts resolved, thus open for votes
again. Would be nice to have it in the next release.
> by-modulator optimization strategy
> --
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The can be a significant difference in performance depending on whether you
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 12.13758.03
> VertexStep(OUT,vertex) 6
> 6 1.345 6.43
> VertexStep(IN,vertex) 12
> 12 0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12
> 12 6.57031.42
> IdStep 36
> 36 0.452
> >TOTAL -
> - 20.916-
> gremlin> g.V().out().in().path().by(id).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> TinkerGraphStep(vertex,[]) 6
> 6 0.87611.54
> VertexStep(OUT,vertex) 6
> 6 0.714 9.40
> VertexStep(IN,vertex) 12
> 12 3.29943.43
> PathStep([id])12
> 12 2.70635.63
> >TOTAL -
> - 7.596-
> {noformat}
> We should have a strategy that rewrites these simple patterns. This affects
> {{id()}}, {{label()}}, {{key()}}, {{value()}}, but also
> {{by(values("name"))}}, which can be rewritten as {{by("name")}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #621: TINKERPOP-1682 by-modulator optimization strategy
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/621 Rebased, issues addressed and conflicts resolved, thus open for votes again. Would be nice to have it in the next release. ---
[jira] [Commented] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408493#comment-16408493
]
Daniel Weber commented on TINKERPOP-1924:
-
Also, project(...) would not take values of type T (as T.id) as well. That
could be another case where to possibly relax the signature.
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408176#comment-16408176
]
Daniel Weber edited comment on TINKERPOP-1924 at 3/21/18 4:23 PM:
--
I don't have the specific need of such output. I am developing an ORM for
Gremlin in C# ([https://github.com/ExRam/ExRam.Gremlinq]) and stumbled upon
this inbalance of the Gremlin-API. The workaround using union is tested here
([https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Tests/GremlinQueryLanguageTest.cs#L1509)]
and is a bit ugly, so I wanted to point it out and possibly improve this.
was (Author: daniel.weber):
I don't have the specific need of such output. I am developing an ORM for
Gremlin in C# (https://github.com/ExRam/ExRam.Gremlinq) and stumbled upon this
inbalance of the Gremlin-API. The workaround for union is tested here
([https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Tests/GremlinQueryLanguageTest.cs#L1509)]
and is a bit ugly, so I wanted to point it out and possibly improve this.
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408176#comment-16408176
]
Daniel Weber commented on TINKERPOP-1924:
-
I don't have the specific need of such output. I am developing an ORM for
Gremlin in C# (https://github.com/ExRam/ExRam.Gremlinq) and stumbled upon this
inbalance of the Gremlin-API. The workaround for union is tested here
([https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Tests/GremlinQueryLanguageTest.cs#L1509)]
and is a bit ugly, so I wanted to point it out and possibly improve this.
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408155#comment-16408155
]
stephen mallette commented on TINKERPOP-1924:
-
hmmm - didn't realize that you specifically wanted that kind of output. Seems a
bit of an odd way to want shape your results though, no? is there a specific
use case you could share? in other words, is there some reason that you would
want to return that mix of ids (and possibly labels) and property data as a
stream?
for fun:
{code}
gremlin> g.V().project('name','id').by('name').by(id).select(values).unfold()
==>marko
==>1
==>vadas
==>2
==>lop
==>3
==>josh
==>4
==>ripple
==>5
==>peter
==>6
{code}
obviously, you're {{union()}} approach is nicer. :)
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1866) Support g:T for .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408150#comment-16408150
]
Jorge Bay commented on TINKERPOP-1866:
--
I've changed to Unassigned, as I won't be able to tackle it in the next few
days.
> Support g:T for .NET
>
>
> Key: TINKERPOP-1866
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1866
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Priority: Critical
> Fix For: 3.3.2
>
>
> We didn't have tests for return of {{T}} which can occur with
> {{valueMap(true)}} - adding them on TINKERPOP-1860 exposed the failure in
> .NET. This may or may not be an issue for GraphSON 3.0 only. In GraphSON 2.0,
> {{g:T}} is a defined type, but it is typically not returned from the server
> outside of {{valueMap(true)}}. When that did happen in GraphSON 2.0, {{T}}
> values were simply converted to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-1866) Support g:T for .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay reassigned TINKERPOP-1866:
Assignee: (was: Jorge Bay)
> Support g:T for .NET
>
>
> Key: TINKERPOP-1866
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1866
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Priority: Critical
> Fix For: 3.3.2
>
>
> We didn't have tests for return of {{T}} which can occur with
> {{valueMap(true)}} - adding them on TINKERPOP-1860 exposed the failure in
> .NET. This may or may not be an issue for GraphSON 3.0 only. In GraphSON 2.0,
> {{g:T}} is a defined type, but it is typically not returned from the server
> outside of {{valueMap(true)}}. When that did happen in GraphSON 2.0, {{T}}
> values were simply converted to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] 3.2.8/3.3.2 Release Issues
Just a quick note to mention that we're down to just these two issues in JIRA: https://issues.apache.org/jira/browse/TINKERPOP-1866 https://issues.apache.org/jira/browse/TINKERPOP-1865 (has a PR at https://github.com/apache/tinkerpop/pull/820) any others? Looks like we might get this all closed up by code freeze on Friday On Mon, Mar 12, 2018 at 12:11 PM, Stephen Mallette wrote: > I just made an update on two issues that I thought needed to be done with > gremlin-python for release, specifically: > > https://issues.apache.org/jira/browse/TINKERPOP-1898 > https://issues.apache.org/jira/browse/TINKERPOP-1895 > > if you're following along, i basically closed 1895 as a duplicate of 1898 > as the two issues are related - ultimately, the issues is with specifying > strategies when a lambda is present. basically, i can't get the test i had > validating a fix to pass consistently and I believe that the reason is > related to something that is out of our hands - an issue in jython > processing varargs. Anyway, i don't imagine 1898 will get closed in time > for release, but personally, I don't think this is a massive issue to block > us from moving forward. I also think we have a reasonable workaround as > gremlin-python users should be able to submit their lambdas as groovy and > get a successful traversal execution. > > > > On Thu, Mar 8, 2018 at 9:42 AM, Florian Hockmann > wrote: > >> I already started working on TINKERPOP-1901, but some tests failed and I >> wanted to use a Docker image of the Gremlin Server for easier debugging >> which is why I created a PR for that first. >> Finishing TINKERPOP-1854 should be really easy once TINKERPOP-1901 is >> done. >> >> Supporting g:T (TINKERPOP-1866) shouldn't require much work. It should >> just need a small deserializer. >> >> But I'm not sure about the test related tickets (TINKERPOP-1865 and >> TINKERPOP-1892). I looked into the failing tests when the new scenarios >> were introduced and they seemed to be caused by bugs / missing >> functionality in the way we create traversals from the Gherkin features >> rather than real bugs in Gremlin.Net. >> >> I also still see the problem of releasing Gremlin.Net from a Unix system >> as strong name signing is still not supported. The newest Visual Studio >> version that was released on Monday (15.6) includes the fix, but we still >> have to wait for the next release of the dotnet CLI tool. I asked in their >> Gitter channel about an estimate but didn't get an answer so far. We might >> have to set up a small build job on AppVeyor to build and pack Gremlin.Net >> so that the release manager can download the NuGet packages from there and >> then only has to push them. I can't handle the NuGet packaging this time as >> I'm on vacation in the second half of March and first week of April. >> >> Do we have to set the release date in stone now or could we just see >> where we are at the end of next week and then decide whether we stay with >> the release date in the first week of April or whether we need more time? >> >> -Ursprüngliche Nachricht- >> Von: Jorge Bay Gondra >> Gesendet: Donnerstag, 8. März 2018 09:26 >> An: dev@tinkerpop.apache.org >> Betreff: Re: [DISCUSS] 3.2.8/3.3.2 Release Issues >> >> Lambdas in .NET is blocked by TINKERPOP-1901, I've updated JIRA to >> reflect that. >> >> I don't know if we can make it with the current scope in that timeline. I >> have very little / no time available for the .NET GLV issues until the end >> of next week... >> >> On Wed, Mar 7, 2018 at 9:35 PM, Stephen Mallette >> wrote: >> >> > In a previous thread we had the idea that we would look to release >> > 3.2.8/3.3.2 around the first week of April which means that we will >> > likely code freeze in about 10 days to focus on review/test/docs. I >> > think that we want to see these issues polished up before we release: >> > >> > https://issues.apache.org/jira/browse/TINKERPOP-1866 (Support g:T for >> > .NET) >> > https://issues.apache.org/jira/browse/TINKERPOP-1854 (Lambdas in .NET >> > - already has a PR) >> > https://issues.apache.org/jira/browse/TINKERPOP-1865 (Run .NET tests >> > on GraphSON 3.0) >> > https://issues.apache.org/jira/browse/TINKERPOP-1892 (A few failing >> > tests in .NET) >> > >> > Jorge/Florian, hopefully you can help us get to the finish line on >> > those .NET issues? >> > >> > The following 3 are all python related around lambdas and i think >> > fixing one will fix all (i'm still digging into these): >> > >> > https://issues.apache.org/jira/browse/TINKERPOP-1895 >> > https://issues.apache.org/jira/browse/TINKERPOP-1896 >> > https://issues.apache.org/jira/browse/TINKERPOP-1898 >> > >> > Obviously we would want to close out all current PRs that are open as >> well. >> > Committers, we could use some reviews please - there is a glut of them >> > at this point. >> > >> > Interestingly there's no problems to solve with the Javascript GLV...I >> > guess I shouldn't be paranoid :) >> > >> > Are there an
[jira] [Comment Edited] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408140#comment-16408140
]
Daniel Weber edited comment on TINKERPOP-1924 at 3/21/18 3:57 PM:
--
Because what you get from these queries are maps. What
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
would return is a list of scalars, i.e.
{code:java}
==>1
==>marko
==>2
==>vadas
==>3
...
{code}
was (Author: daniel.weber):
Because what you get from these queries are maps. What
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
would return is a list, i.e.
{code:java}
==>1
==>marko
==>2
==>vadas
==>3
...
{code}
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408140#comment-16408140
]
Daniel Weber commented on TINKERPOP-1924:
-
Because what you get from these queries are maps. What
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
would return is a list, i.e.
{code:java}
==>1
==>marko
==>2
==>vadas
==>3
...
{code}
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408120#comment-16408120
]
stephen mallette commented on TINKERPOP-1924:
-
Any reason that these these options to include id/label in your output are not
sufficient?
{code}
gremlin> g.V().valueMap(true,'name')
==>[id:1,name:[marko],label:person]
==>[id:2,name:[vadas],label:person]
==>[id:3,name:[lop],label:software]
==>[id:4,name:[josh],label:person]
==>[id:5,name:[ripple],label:software]
==>[id:6,name:[peter],label:person]
gremlin> g.V().project('name','id').by('name').by(id)
==>[name:marko,id:1]
==>[name:vadas,id:2]
==>[name:lop,id:3]
==>[name:josh,id:4]
==>[name:ripple,id:5]
==>[name:peter,id:6]
{code}
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1923) Intermittent NegativeArraySizeException on drop
[
https://issues.apache.org/jira/browse/TINKERPOP-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408099#comment-16408099
]
stephen mallette commented on TINKERPOP-1923:
-
[~james.d.baker] is there any chance you are modifying this TinkerGraph from
multiple threads? I can't seem to think of how else this problem would pop up?
Is there anything else to your code that might be relevant?
> Intermittent NegativeArraySizeException on drop
> ---
>
> Key: TINKERPOP-1923
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1923
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.3.1
>Reporter: James Baker
>Priority: Major
>
> I am intermittently getting the following exception when dropping vertices on
> a TinkerGraph:
> {noformat}
> Exception in thread "main" java.lang.NegativeArraySizeException
> at java.util.AbstractCollection.toArray(AbstractCollection.java:136)
> at java.util.ArrayList.addAll(ArrayList.java:581)
> at java.util.HashMap$Values.forEach(HashMap.java:981)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerHelper.getEdges(TinkerHelper.java:172)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.edges(TinkerVertex.java:146)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.remove(TinkerVertex.java:131)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.DropStep.filter(DropStep.java:67)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.iterate(Traversal.java:203)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.iterate(GraphTraversal.java:2664)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal$Admin.iterate(GraphTraversal.java:177)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.DefaultGraphTraversal.iterate(DefaultGraphTraversal.java:48)
> at mycode.merge.GraphMerger.mergeVertices(GraphMerger.java:172)
> at mycode.merge.GraphMerger.lambda$mergeGraphs$6(GraphMerger.java:78)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at mycode.merge.GraphMerger.mergeGraphs(GraphMerger.java:79)
> at mycode.cli.mapper.MergeGraphFiles.main(MergeGraphFiles.java:117)
> {noformat}
> My code is as follows (the last line is Line 172, which is where the
> exception is thrown):
> {code:java}
> LOGGER.info("Removing original vertices");
> Object[] ids = mergeGroup.stream().map(Element::id).toArray();
> LOGGER.debug("IDs to remove {}", ids);
> if(ids != null && ids.length > 0)
> graph.traversal().V(ids).drop().iterate();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] Use error-prone java compiler
It has multi-language support - https://community.synopsys.com/s/question/0D5343WcsSiCAJ/what-languages-are-supported-by-synopsys-static-analysis-coverity Robert Dale On Wed, Mar 21, 2018 at 10:01 AM, Robert Dale wrote: > Another option might be to use Coverity - https://scan.coverity.com/faq - > and run it in Travis CI > > Robert Dale > > On Wed, Mar 21, 2018 at 9:43 AM, Stephen Mallette > wrote: > >> > I think any proposed changes would be separate PRs and reviewed on a >> case-by-case >> basis. >> >> yeah - i think if we want something like this the goal should first be to >> decide on a tool (i can't say that i agree with Roman that "running more >> tools is always better" btw). note i'm still saying, "if we want something >> like this" because while i'm not against it I'd like to be convinced that >> we need to worry about this now at this stage of TinkerPop's development. >> i'd have been more inclined to deal with this early on in TinkerPop's >> development rather than now. And, yes, also agree that i would like to see >> the tool in first and then each introduction of "rule" be a separate >> discussion and PR. >> >> > As for making it the default compiler, I think this would be a profile, >> disabled by default, at best at least until a time it can be massaged to >> where it works for this project. >> >> yeahthat might be a smart way to go >> >> > whether other static analysis tools would find most of the problems >> that >> such a compiler can find and also work with other languages than Java. >> >> very good thought. while the bulk of our code is java, we are far from a >> single language code base. if there is one tool that can give us some nice >> clean analysis across the entire code base, perhaps that's the best way to >> go (again, "if we want something like this"). >> >> >> >> >> On Tue, Mar 20, 2018 at 8:41 AM, Florian Hockmann > > >> wrote: >> >> > In general, I am +1 on adding a static analysis tool to our tool chain. >> > I just wonder whether a Java compiler is the best choice for us right >> > now or whether other static analysis tools would find most of the >> > problems that such a compiler can find and also work with other >> > languages than Java. SonarQube[1] for example looks pretty nice. It also >> > supports Python, C#, and JavaScript and we can probably just integrate >> > it via GitHub to generate reports for the release branches and all PRs >> > where it would then add issues in the form of inline comments. >> > >> > [1] https://www.sonarqube.org/ >> > >> > Am 20.03.2018 um 03:42 schrieb Robert Dale: >> > > Some changes look good others look wrong evident by the failed >> builds. I >> > > think any proposed changes would be separate PRs and reviewed on a >> > > case-by-case basis. As for making it the default compiler, I think >> this >> > > would be a profile, disabled by default, at best at least until a >> time it >> > > can be massaged to where it works for this project. >> > > >> > > On Mon, Mar 19, 2018 at 14:59 Roman Leventov >> > wrote: >> > > >> > >> See https://github.com/apache/tinkerpop/pull/819. >> > >> >> > >> 1) Are there any objections to using error-prone compiler instead of >> > >> OpenJDK's javac compiler? >> > >> 2) Stephen raised the question, that Tinkerpop project may better use >> > >> another static analysis tool instead of error-prone. I have to answer >> > that >> > >> no static analysis tool covers 100% of the errors found by any other >> > tool, >> > >> so running more tools is always better. >> > >> 3) Stephen raised the question, what checks should be enabled. I >> believe >> > >> this is out of scope of the PR ( >> > >> https://github.com/apache/tinkerpop/pull/819), >> > >> because it doesn't (and doesn't intent to) enable any more checks >> > beyond >> > >> the default (= minimal) set of error patterns. More checks may or may >> > not >> > >> be enabled in later PRs and that could be discussed separately. >> > >> >> > >> > >> > >> > >
Re: [DISCUSS] Use error-prone java compiler
Another option might be to use Coverity - https://scan.coverity.com/faq - and run it in Travis CI Robert Dale On Wed, Mar 21, 2018 at 9:43 AM, Stephen Mallette wrote: > > I think any proposed changes would be separate PRs and reviewed on a > case-by-case > basis. > > yeah - i think if we want something like this the goal should first be to > decide on a tool (i can't say that i agree with Roman that "running more > tools is always better" btw). note i'm still saying, "if we want something > like this" because while i'm not against it I'd like to be convinced that > we need to worry about this now at this stage of TinkerPop's development. > i'd have been more inclined to deal with this early on in TinkerPop's > development rather than now. And, yes, also agree that i would like to see > the tool in first and then each introduction of "rule" be a separate > discussion and PR. > > > As for making it the default compiler, I think this would be a profile, > disabled by default, at best at least until a time it can be massaged to > where it works for this project. > > yeahthat might be a smart way to go > > > whether other static analysis tools would find most of the problems that > such a compiler can find and also work with other languages than Java. > > very good thought. while the bulk of our code is java, we are far from a > single language code base. if there is one tool that can give us some nice > clean analysis across the entire code base, perhaps that's the best way to > go (again, "if we want something like this"). > > > > > On Tue, Mar 20, 2018 at 8:41 AM, Florian Hockmann > wrote: > > > In general, I am +1 on adding a static analysis tool to our tool chain. > > I just wonder whether a Java compiler is the best choice for us right > > now or whether other static analysis tools would find most of the > > problems that such a compiler can find and also work with other > > languages than Java. SonarQube[1] for example looks pretty nice. It also > > supports Python, C#, and JavaScript and we can probably just integrate > > it via GitHub to generate reports for the release branches and all PRs > > where it would then add issues in the form of inline comments. > > > > [1] https://www.sonarqube.org/ > > > > Am 20.03.2018 um 03:42 schrieb Robert Dale: > > > Some changes look good others look wrong evident by the failed > builds. I > > > think any proposed changes would be separate PRs and reviewed on a > > > case-by-case basis. As for making it the default compiler, I think > this > > > would be a profile, disabled by default, at best at least until a time > it > > > can be massaged to where it works for this project. > > > > > > On Mon, Mar 19, 2018 at 14:59 Roman Leventov > > wrote: > > > > > >> See https://github.com/apache/tinkerpop/pull/819. > > >> > > >> 1) Are there any objections to using error-prone compiler instead of > > >> OpenJDK's javac compiler? > > >> 2) Stephen raised the question, that Tinkerpop project may better use > > >> another static analysis tool instead of error-prone. I have to answer > > that > > >> no static analysis tool covers 100% of the errors found by any other > > tool, > > >> so running more tools is always better. > > >> 3) Stephen raised the question, what checks should be enabled. I > believe > > >> this is out of scope of the PR ( > > >> https://github.com/apache/tinkerpop/pull/819), > > >> because it doesn't (and doesn't intent to) enable any more checks > > beyond > > >> the default (= minimal) set of error patterns. More checks may or may > > not > > >> be enabled in later PRs and that could be discussed separately. > > >> > > > > > > >
Re: [DISCUSS] Use error-prone java compiler
> I think any proposed changes would be separate PRs and reviewed on a > case-by-case basis. yeah - i think if we want something like this the goal should first be to decide on a tool (i can't say that i agree with Roman that "running more tools is always better" btw). note i'm still saying, "if we want something like this" because while i'm not against it I'd like to be convinced that we need to worry about this now at this stage of TinkerPop's development. i'd have been more inclined to deal with this early on in TinkerPop's development rather than now. And, yes, also agree that i would like to see the tool in first and then each introduction of "rule" be a separate discussion and PR. > As for making it the default compiler, I think this would be a profile, disabled by default, at best at least until a time it can be massaged to where it works for this project. yeahthat might be a smart way to go > whether other static analysis tools would find most of the problems that such a compiler can find and also work with other languages than Java. very good thought. while the bulk of our code is java, we are far from a single language code base. if there is one tool that can give us some nice clean analysis across the entire code base, perhaps that's the best way to go (again, "if we want something like this"). On Tue, Mar 20, 2018 at 8:41 AM, Florian Hockmann wrote: > In general, I am +1 on adding a static analysis tool to our tool chain. > I just wonder whether a Java compiler is the best choice for us right > now or whether other static analysis tools would find most of the > problems that such a compiler can find and also work with other > languages than Java. SonarQube[1] for example looks pretty nice. It also > supports Python, C#, and JavaScript and we can probably just integrate > it via GitHub to generate reports for the release branches and all PRs > where it would then add issues in the form of inline comments. > > [1] https://www.sonarqube.org/ > > Am 20.03.2018 um 03:42 schrieb Robert Dale: > > Some changes look good others look wrong evident by the failed builds. I > > think any proposed changes would be separate PRs and reviewed on a > > case-by-case basis. As for making it the default compiler, I think this > > would be a profile, disabled by default, at best at least until a time it > > can be massaged to where it works for this project. > > > > On Mon, Mar 19, 2018 at 14:59 Roman Leventov > wrote: > > > >> See https://github.com/apache/tinkerpop/pull/819. > >> > >> 1) Are there any objections to using error-prone compiler instead of > >> OpenJDK's javac compiler? > >> 2) Stephen raised the question, that Tinkerpop project may better use > >> another static analysis tool instead of error-prone. I have to answer > that > >> no static analysis tool covers 100% of the errors found by any other > tool, > >> so running more tools is always better. > >> 3) Stephen raised the question, what checks should be enabled. I believe > >> this is out of scope of the PR ( > >> https://github.com/apache/tinkerpop/pull/819), > >> because it doesn't (and doesn't intent to) enable any more checks > beyond > >> the default (= minimal) set of error patterns. More checks may or may > not > >> be enabled in later PRs and that could be discussed separately. > >> > > >
[jira] [Closed] (TINKERPOP-1758) RemoteStrategy should be before all other DecorationStrategies.
[
https://issues.apache.org/jira/browse/TINKERPOP-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1758.
---
Resolution: Fixed
Fix Version/s: 3.3.2
3.2.8
> RemoteStrategy should be before all other DecorationStrategies.
> ---
>
> Key: TINKERPOP-1758
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1758
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> {code}
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
> gremlin> g.V().out().out().values('name').explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> RemoteStrategy [D]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> MatchPredicateStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> FilterRankingStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> InlineFilterStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> IncidentToAdjacentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> AdjacentToIncidentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> RepeatUnrollStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> CountStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> PathRetractionStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> LazyBarrierStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphCountStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphStepStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> ProfileStrategy [F]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> StandardVerificationStrategy [V]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> Final Traversal
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1758) RemoteStrategy should be before all other DecorationStrategies.
[
https://issues.apache.org/jira/browse/TINKERPOP-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16407793#comment-16407793
]
ASF GitHub Bot commented on TINKERPOP-1758:
---
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/811
> RemoteStrategy should be before all other DecorationStrategies.
> ---
>
> Key: TINKERPOP-1758
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1758
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>
> {code}
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
> gremlin> g.V().out().out().values('name').explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> RemoteStrategy [D]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> MatchPredicateStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> FilterRankingStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> InlineFilterStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> IncidentToAdjacentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> AdjacentToIncidentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> RepeatUnrollStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> CountStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> PathRetractionStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> LazyBarrierStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphCountStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphStepStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> ProfileStrategy [F]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> StandardVerificationStrategy [V]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> Final Traversal
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #811: TINKERPOP-1758 Apply RemoteStrategy before all ...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/811 ---
