[jira] [Commented] (TINKERPOP-1834) Consider iterate() as a first class step

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255959#comment-16255959
 ] 

ASF GitHub Bot commented on TINKERPOP-1834:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
I think we over engineered this ticket. I believe @dkuppitz has the best 
idea.

```
public Traversal iterate() {
  this.filter(false);
  while(hasNext()) {
next();
  } 
  return this;
}
```




> Consider iterate() as a first class step
> 
>
> Key: TINKERPOP-1834
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1834
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>
> The {{iterate()}} terminator on a traversal returns no data. It simply 
> executes the traversal in full typically for the generation of side-effects. 
> Graph providers could optimize a traversal that is iterated should they be 
> able to detect that this method is called as they might avoid certain read 
> operations if the traversal is explicitly meant to just update the graph. 
> A possible solution for this would be some form of direct implementation of 
> an explicit {{IterateStep}} which providers could identify. Or perhaps, a 
> more generic {{NoOpStep}} would be better where the {{NoOpStep}} would 
> basically just be a marker with some meta-data tied to it (i.e. a {{Map}} of 
> arbitrary configuration options). In this case, the configuration options 
> would simply have an "iterate" value in it which the provider could interpret 
> if they could optimize based on that. Other solutions?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
I think we over engineered this ticket. I believe @dkuppitz has the best 
idea.

```
public Traversal iterate() {
  this.filter(false);
  while(hasNext()) {
next();
  } 
  return this;
}
```




---

[jira] [Commented] (TINKERPOP-1784) Gremlin Language Test Suite

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255517#comment-16255517
 ] 

ASF GitHub Bot commented on TINKERPOP-1784:
---

Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/747#discussion_r151456526
  
--- Diff: gremlin-test/features/branch/Choose.feature ---
@@ -0,0 +1,124 @@
+# 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.
+
+Feature: Step - choose()
+
+  Scenario: g_V_chooseXout_countX_optionX2L__nameX_optionX3L__valueMapX
+Given the modern graph
+And the traversal of
+  """
+  g.V().choose(__.out().count()).
+option(2L, __.values("name")).
+option(3L, __.valueMap())
+  """
+When iterated to list
+Then the result should be unordered
+  | result |
+  | m[{"name":["marko"], "age":[29]}] |
--- End diff --

We should specify the expected numeric type when describing map results 
because it has different meaning across different scenarios, here is an 
`int32`, below it's also a `int64` (ie: `groupCount()`) and also a `double`.
The json literal for numbers could be reserved for `double` (JS `Number` 
underlying representation) and the rest we could use something like:
- `m[{"age":"d[29]"}]`,  value is an `int32`.
- `m[{"age":"d[29L]"}]`,  value is an `int64`.
- `m[{"age":29}]`,  value is an `double`.


> Gremlin Language Test Suite
> ---
>
> Key: TINKERPOP-1784
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1784
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Provide for a more language agnostic test framework for the Gremlin Language 
> so that we can properly test GLVs. The current test suite is completely tied 
> to the JVM.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #747: TINKERPOP-1784 GLV Test Framework

[jorgebay]

Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/747#discussion_r151456526
  
--- Diff: gremlin-test/features/branch/Choose.feature ---
@@ -0,0 +1,124 @@
+# 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.
+
+Feature: Step - choose()
+
+  Scenario: g_V_chooseXout_countX_optionX2L__nameX_optionX3L__valueMapX
+Given the modern graph
+And the traversal of
+  """
+  g.V().choose(__.out().count()).
+option(2L, __.values("name")).
+option(3L, __.valueMap())
+  """
+When iterated to list
+Then the result should be unordered
+  | result |
+  | m[{"name":["marko"], "age":[29]}] |
--- End diff --

We should specify the expected numeric type when describing map results 
because it has different meaning across different scenarios, here is an 
`int32`, below it's also a `int64` (ie: `groupCount()`) and also a `double`.
The json literal for numbers could be reserved for `double` (JS `Number` 
underlying representation) and the rest we could use something like:
- `m[{"age":"d[29]"}]`,  value is an `int32`.
- `m[{"age":"d[29L]"}]`,  value is an `int64`.
- `m[{"age":29}]`,  value is an `double`.


---

[jira] [Created] (TINKERPOP-1836) .NET sample project

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1836:
---

 Summary: .NET sample project
 Key: TINKERPOP-1836
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1836
 Project: TinkerPop
  Issue Type: Improvement
  Components: dotnet
Affects Versions: 3.2.6
Reporter: stephen mallette
Priority: Minor


Create a sample project that can help get users started with .NET and Gremlin. 
Should probably be added to the series of gremlin-archetype projects. It seems 
.NET already has something analogous to archetypes with "dotnet templates". I'm 
not sure how those work or are built/deployed/distributed but we would probably 
want to ensure that those aspects are somehow still handled by maven if we can.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1834) Consider iterate() as a first class step

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255419#comment-16255419
 ] 

ASF GitHub Bot commented on TINKERPOP-1834:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
Makes sense.


> Consider iterate() as a first class step
> 
>
> Key: TINKERPOP-1834
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1834
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>
> The {{iterate()}} terminator on a traversal returns no data. It simply 
> executes the traversal in full typically for the generation of side-effects. 
> Graph providers could optimize a traversal that is iterated should they be 
> able to detect that this method is called as they might avoid certain read 
> operations if the traversal is explicitly meant to just update the graph. 
> A possible solution for this would be some form of direct implementation of 
> an explicit {{IterateStep}} which providers could identify. Or perhaps, a 
> more generic {{NoOpStep}} would be better where the {{NoOpStep}} would 
> basically just be a marker with some meta-data tied to it (i.e. a {{Map}} of 
> arbitrary configuration options). In this case, the configuration options 
> would simply have an "iterate" value in it which the provider could interpret 
> if they could optimize based on that. Other solutions?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
Makes sense.


---

[jira] [Commented] (TINKERPOP-1834) Consider iterate() as a first class step

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255392#comment-16255392
 ] 

ASF GitHub Bot commented on TINKERPOP-1834:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
In reviewing this, I think Gremlin Server needs a change. When we submit a 
remote traversal. Gremlin Server needs to check for `iterate()` in the bytecode 
and actually call `iterate()` rather than `next()` that way the graph instance 
gets the right method called on it for any additional optimization that could 
occur there. Plus, if the client did call `iterate()` it's better that Gremlin 
Server simply return no results - that's a big optimization. I can work on that 
change and just commit it to this branch as part of this PR.


> Consider iterate() as a first class step
> 
>
> Key: TINKERPOP-1834
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1834
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>
> The {{iterate()}} terminator on a traversal returns no data. It simply 
> executes the traversal in full typically for the generation of side-effects. 
> Graph providers could optimize a traversal that is iterated should they be 
> able to detect that this method is called as they might avoid certain read 
> operations if the traversal is explicitly meant to just update the graph. 
> A possible solution for this would be some form of direct implementation of 
> an explicit {{IterateStep}} which providers could identify. Or perhaps, a 
> more generic {{NoOpStep}} would be better where the {{NoOpStep}} would 
> basically just be a marker with some meta-data tied to it (i.e. a {{Map}} of 
> arbitrary configuration options). In this case, the configuration options 
> would simply have an "iterate" value in it which the provider could interpret 
> if they could optimize based on that. Other solutions?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
In reviewing this, I think Gremlin Server needs a change. When we submit a 
remote traversal. Gremlin Server needs to check for `iterate()` in the bytecode 
and actually call `iterate()` rather than `next()` that way the graph instance 
gets the right method called on it for any additional optimization that could 
occur there. Plus, if the client did call `iterate()` it's better that Gremlin 
Server simply return no results - that's a big optimization. I can work on that 
change and just commit it to this branch as part of this PR.


---

[GitHub] tinkerpop pull request #749: Tinkerpop 1807 Gremlin-Python doesn't support G...

[spmallette]

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/749#discussion_r151390209
  
--- Diff: docs/src/upgrade/release-3.3.x.asciidoc ---
@@ -29,6 +29,15 @@ Please see the 
link:https://github.com/apache/tinkerpop/blob/3.3.1/CHANGELOG.asc
 
 === Upgrading for Users
 
+ Gremlin-Python Core Types
--- End diff --

You can remove this - no need to duplicate it. We direct users to 3.2.x 
upgrade notes as being inclusive of the 3.3.x ones.


---

[GitHub] tinkerpop issue #749: Tinkerpop 1807 Gremlin-Python doesn't support GraphSON...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/749
  
You don't need a changelog for 3.3.1. we isolate the fix to the earliest 
release it was fixed on.


---