[jira] [Commented] (TINKERPOP-1418) CoreTraversalTests depend on missing functionality

[Benjamin Anderson (JIRA)]

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

Benjamin Anderson commented on TINKERPOP-1418:
--

Alrighty. There's a dozen or so references in the comments for 
{{Graph.vertices}} and {{Graph.edges}} that pretty clearly point to element ids.

Out of curiosity, why was this behavior removed from GraphStep and pushed down 
to the implementor?

> CoreTraversalTests depend on missing functionality
> --
>
> Key: TINKERPOP-1418
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1418
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure, test-suite
>Affects Versions: 3.2.1
>Reporter: Benjamin Anderson
>Priority: Minor
>
> The {{shouldLoadVerticesViaVertices}} and {{shouldLoadEdgesViaEdges}} tests 
> in 
> [CoreTraversalTests.java|https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L94-L110]
>  appear to depend on unspecified functionality.
> The comment for the {{.vertices}} method in the Graph structure class does 
> not specify that it should accept Vertex objects (except in [one odd 
> place|https://github.com/apache/tinkerpop/blob/d696b38ab774dd46c6723d5c59aa7329f96b41e1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java#L219])
>  - as an implementor it reads as if it's intended to be called only with 
> identifiers.
> [When these two tests were 
> added|https://github.com/apache/tinkerpop/commit/da30a525ef626b8f13ffba0b7abada89b68eff6b]
>  some functionality was included in GraphStep to handle mapping Vertex 
> objects to their IDs; this functionality was [soon 
> removed|https://github.com/apache/tinkerpop/commit/59028c8ad18f23609e31220a59717a2bc05b78af],
>  however, and added to TinkerGraph. Incidentally, Titan [also implements the 
> same 
> functionality|https://github.com/thinkaurelius/titan/blob/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/TitanBlueprintsTransaction.java#L113-L141].
> Is {{Graph.vertices(Object...)}} intended to gracefully handle an array of 
> Vertex elements as well as an array of Vertex identifiers? If so, then it 
> appears that the documentation in Graph.java needs some reworking. It'd also 
> perhaps be unfortunate, stylistically, to add a third behavior to that 
> method. If it's not intended to support that call, then it seems that these 
> two methods (and perhaps others?) should be removed from the test suite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1418) CoreTraversalTests depend on missing functionality

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1418:
-

The intention is to allow:

{code}
Vertex v = 
graph.vertices(v)
{code}

Documentation could be more clear on that 

> CoreTraversalTests depend on missing functionality
> --
>
> Key: TINKERPOP-1418
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1418
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure, test-suite
>Affects Versions: 3.2.1
>Reporter: Benjamin Anderson
>Priority: Minor
>
> The {{shouldLoadVerticesViaVertices}} and {{shouldLoadEdgesViaEdges}} tests 
> in 
> [CoreTraversalTests.java|https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L94-L110]
>  appear to depend on unspecified functionality.
> The comment for the {{.vertices}} method in the Graph structure class does 
> not specify that it should accept Vertex objects (except in [one odd 
> place|https://github.com/apache/tinkerpop/blob/d696b38ab774dd46c6723d5c59aa7329f96b41e1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java#L219])
>  - as an implementor it reads as if it's intended to be called only with 
> identifiers.
> [When these two tests were 
> added|https://github.com/apache/tinkerpop/commit/da30a525ef626b8f13ffba0b7abada89b68eff6b]
>  some functionality was included in GraphStep to handle mapping Vertex 
> objects to their IDs; this functionality was [soon 
> removed|https://github.com/apache/tinkerpop/commit/59028c8ad18f23609e31220a59717a2bc05b78af],
>  however, and added to TinkerGraph. Incidentally, Titan [also implements the 
> same 
> functionality|https://github.com/thinkaurelius/titan/blob/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/TitanBlueprintsTransaction.java#L113-L141].
> Is {{Graph.vertices(Object...)}} intended to gracefully handle an array of 
> Vertex elements as well as an array of Vertex identifiers? If so, then it 
> appears that the documentation in Graph.java needs some reworking. It'd also 
> perhaps be unfortunate, stylistically, to add a third behavior to that 
> method. If it's not intended to support that call, then it seems that these 
> two methods (and perhaps others?) should be removed from the test suite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1418) CoreTraversalTests depend on missing functionality

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1418:
-

The intention is to allow:

{code}
Vertex v = 
graph.vertices(v)
{code}

Documentation could be more clear on that 

> CoreTraversalTests depend on missing functionality
> --
>
> Key: TINKERPOP-1418
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1418
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure, test-suite
>Affects Versions: 3.2.1
>Reporter: Benjamin Anderson
>Priority: Minor
>
> The {{shouldLoadVerticesViaVertices}} and {{shouldLoadEdgesViaEdges}} tests 
> in 
> [CoreTraversalTests.java|https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L94-L110]
>  appear to depend on unspecified functionality.
> The comment for the {{.vertices}} method in the Graph structure class does 
> not specify that it should accept Vertex objects (except in [one odd 
> place|https://github.com/apache/tinkerpop/blob/d696b38ab774dd46c6723d5c59aa7329f96b41e1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java#L219])
>  - as an implementor it reads as if it's intended to be called only with 
> identifiers.
> [When these two tests were 
> added|https://github.com/apache/tinkerpop/commit/da30a525ef626b8f13ffba0b7abada89b68eff6b]
>  some functionality was included in GraphStep to handle mapping Vertex 
> objects to their IDs; this functionality was [soon 
> removed|https://github.com/apache/tinkerpop/commit/59028c8ad18f23609e31220a59717a2bc05b78af],
>  however, and added to TinkerGraph. Incidentally, Titan [also implements the 
> same 
> functionality|https://github.com/thinkaurelius/titan/blob/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/TitanBlueprintsTransaction.java#L113-L141].
> Is {{Graph.vertices(Object...)}} intended to gracefully handle an array of 
> Vertex elements as well as an array of Vertex identifiers? If so, then it 
> appears that the documentation in Graph.java needs some reworking. It'd also 
> perhaps be unfortunate, stylistically, to add a third behavior to that 
> method. If it's not intended to support that call, then it seems that these 
> two methods (and perhaps others?) should be removed from the test suite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (TINKERPOP-1418) CoreTraversalTests depend on missing functionality

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1418:

Comment: was deleted

(was: The intention is to allow:

{code}
Vertex v = 
graph.vertices(v)
{code}

Documentation could be more clear on that )

> CoreTraversalTests depend on missing functionality
> --
>
> Key: TINKERPOP-1418
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1418
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure, test-suite
>Affects Versions: 3.2.1
>Reporter: Benjamin Anderson
>Priority: Minor
>
> The {{shouldLoadVerticesViaVertices}} and {{shouldLoadEdgesViaEdges}} tests 
> in 
> [CoreTraversalTests.java|https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L94-L110]
>  appear to depend on unspecified functionality.
> The comment for the {{.vertices}} method in the Graph structure class does 
> not specify that it should accept Vertex objects (except in [one odd 
> place|https://github.com/apache/tinkerpop/blob/d696b38ab774dd46c6723d5c59aa7329f96b41e1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java#L219])
>  - as an implementor it reads as if it's intended to be called only with 
> identifiers.
> [When these two tests were 
> added|https://github.com/apache/tinkerpop/commit/da30a525ef626b8f13ffba0b7abada89b68eff6b]
>  some functionality was included in GraphStep to handle mapping Vertex 
> objects to their IDs; this functionality was [soon 
> removed|https://github.com/apache/tinkerpop/commit/59028c8ad18f23609e31220a59717a2bc05b78af],
>  however, and added to TinkerGraph. Incidentally, Titan [also implements the 
> same 
> functionality|https://github.com/thinkaurelius/titan/blob/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/TitanBlueprintsTransaction.java#L113-L141].
> Is {{Graph.vertices(Object...)}} intended to gracefully handle an array of 
> Vertex elements as well as an array of Vertex identifiers? If so, then it 
> appears that the documentation in Graph.java needs some reworking. It'd also 
> perhaps be unfortunate, stylistically, to add a third behavior to that 
> method. If it's not intended to support that call, then it seems that these 
> two methods (and perhaps others?) should be removed from the test suite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TINKERPOP-1418) CoreTraversalTests depend on missing functionality

[Benjamin Anderson (JIRA)]

Benjamin Anderson created TINKERPOP-1418:


 Summary: CoreTraversalTests depend on missing functionality
 Key: TINKERPOP-1418
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1418
 Project: TinkerPop
  Issue Type: Bug
  Components: structure, test-suite
Affects Versions: 3.2.1
Reporter: Benjamin Anderson
Priority: Minor


The {{shouldLoadVerticesViaVertices}} and {{shouldLoadEdgesViaEdges}} tests in 
[CoreTraversalTests.java|https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L94-L110]
 appear to depend on unspecified functionality.

The comment for the {{.vertices}} method in the Graph structure class does not 
specify that it should accept Vertex objects (except in [one odd 
place|https://github.com/apache/tinkerpop/blob/d696b38ab774dd46c6723d5c59aa7329f96b41e1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java#L219])
 - as an implementor it reads as if it's intended to be called only with 
identifiers.

[When these two tests were 
added|https://github.com/apache/tinkerpop/commit/da30a525ef626b8f13ffba0b7abada89b68eff6b]
 some functionality was included in GraphStep to handle mapping Vertex objects 
to their IDs; this functionality was [soon 
removed|https://github.com/apache/tinkerpop/commit/59028c8ad18f23609e31220a59717a2bc05b78af],
 however, and added to TinkerGraph. Incidentally, Titan [also implements the 
same 
functionality|https://github.com/thinkaurelius/titan/blob/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/TitanBlueprintsTransaction.java#L113-L141].

Is {{Graph.vertices(Object...)}} intended to gracefully handle an array of 
Vertex elements as well as an array of Vertex identifiers? If so, then it 
appears that the documentation in Graph.java needs some reworking. It'd also 
perhaps be unfortunate, stylistically, to add a third behavior to that method. 
If it's not intended to support that call, then it seems that these two methods 
(and perhaps others?) should be removed from the test suite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #390: GraphSON 2.0 Deser tweaks and improvements

[newkek]

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/390
  
Seems like it is only on my machine... I think Stephen tried on the docker 
image ?
Yes what I have seen so far is it happens at the moment we call 
`deserializationContext.findContextualValueDeserializer(typeFromId)` in 
`GraphSONTypeDeserializer` where the `typeFromId` is the type that has been 
constructed at init time with 
`TypeFactory.defaultInstance().constructType(Tree.class)`. I also see that for 
some reason I don't get, it happens to me only when the [Enums 
types](https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L131-L140)
 from the Traversal serialzers have been constructed as well. If I comment 
those lines, I've got no problem when doing constructType(Tree.class) like all 
the rest..


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

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

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

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/390
  
Seems like it is only on my machine... I think Stephen tried on the docker 
image ?
Yes what I have seen so far is it happens at the moment we call 
`deserializationContext.findContextualValueDeserializer(typeFromId)` in 
`GraphSONTypeDeserializer` where the `typeFromId` is the type that has been 
constructed at init time with 
`TypeFactory.defaultInstance().constructType(Tree.class)`. I also see that for 
some reason I don't get, it happens to me only when the [Enums 
types](https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L131-L140)
 from the Traversal serialzers have been constructed as well. If I comment 
those lines, I've got no problem when doing constructType(Tree.class) like all 
the rest..


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1386) Bump to Netty 4.0.39.Final

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1386:

Fix Version/s: (was: 3.1.4)

> Bump to Netty 4.0.39.Final
> --
>
> Key: TINKERPOP-1386
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1386
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.2
>
>
> Consider bumping Netty to 4.0.39.Final - there are a number of bug/security 
> fixes available.
> http://netty.io/news/2016/03/21/4-0-35-Final.html
> http://netty.io/news/2016/04/04/4-0-36-Final.html
> http://netty.io/news/2016/06/07/4-0-37-Final.html
> http://netty.io/news/2016/07/01/4-0-38-Final-4-1-2-Final.html
> http://netty.io/news/2016/07/15/4-0-39-Final-4-1-3-Final.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (TINKERPOP-1386) Bump to Netty 4.0.39.Final

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette reopened TINKERPOP-1386:
-

> Bump to Netty 4.0.39.Final
> --
>
> Key: TINKERPOP-1386
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1386
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.2
>
>
> Consider bumping Netty to 4.0.39.Final - there are a number of bug/security 
> fixes available.
> http://netty.io/news/2016/03/21/4-0-35-Final.html
> http://netty.io/news/2016/04/04/4-0-36-Final.html
> http://netty.io/news/2016/06/07/4-0-37-Final.html
> http://netty.io/news/2016/07/01/4-0-38-Final-4-1-2-Final.html
> http://netty.io/news/2016/07/15/4-0-39-Final-4-1-3-Final.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1386) Bump to Netty 4.0.40.Final

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1386:

Summary: Bump to Netty 4.0.40.Final  (was: Bump to Netty 4.0.39.Final)

> Bump to Netty 4.0.40.Final
> --
>
> Key: TINKERPOP-1386
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1386
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.2
>
>
> Consider bumping Netty to 4.0.39.Final - there are a number of bug/security 
> fixes available.
> http://netty.io/news/2016/03/21/4-0-35-Final.html
> http://netty.io/news/2016/04/04/4-0-36-Final.html
> http://netty.io/news/2016/06/07/4-0-37-Final.html
> http://netty.io/news/2016/07/01/4-0-38-Final-4-1-2-Final.html
> http://netty.io/news/2016/07/15/4-0-39-Final-4-1-3-Final.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1386) Bump to Netty 4.0.39.Final

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1386.
---
Resolution: Done

> Bump to Netty 4.0.39.Final
> --
>
> Key: TINKERPOP-1386
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1386
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.2
>
>
> Consider bumping Netty to 4.0.39.Final - there are a number of bug/security 
> fixes available.
> http://netty.io/news/2016/03/21/4-0-35-Final.html
> http://netty.io/news/2016/04/04/4-0-36-Final.html
> http://netty.io/news/2016/06/07/4-0-37-Final.html
> http://netty.io/news/2016/07/01/4-0-38-Final-4-1-2-Final.html
> http://netty.io/news/2016/07/15/4-0-39-Final-4-1-3-Final.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #387: TINKERPOP-1386 Bumped to Netty 4.0.40.final

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/387


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #390: GraphSON 2.0 Deser tweaks and improvements

[PommeVerte]

Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/390
  
Hmmm. I haven't seen this crop up since it was fixed by upgrading Jackson 
to `2.7.2`. Though originally my issue was related to the serializing and not 
deserializing so there may be something else at play. 

What's weird is that in travis' environment this doesn't seem to be an 
issue. 
Have you tried with the docker image? Do you still get errors there? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #390: GraphSON 2.0 Deser tweaks and improvements

[newkek]

GitHub user newkek opened a pull request:

https://github.com/apache/tinkerpop/pull/390

GraphSON 2.0 Deser tweaks and improvements

There's 2 commits: 

- the first brings a massive improvement to the GraphSON 2.0 
deserialization, avoiding a lot of useless copies done on the JSON parser when 
parsing to detect a type in the payload. There's in almost every case no copy 
done anymore, thus reducing the memory impact and improves performances.
- second fixes a bug I had on my machine that was causing a StackOverflow 
exception when deserializing a `Tree` from GraphSON2.0. The issue has been 
pinned down to understanding that there could be a never-ending recursive 
reference when creating a `JavaType` to be indexed in the 
GraphSONTypeIdResolver. All detailed in comments in the code but now I have a 
special case for when a `Tree` is registered that force a non-cyclic reference 
type. It is still unclear to me why this happens to me but not all the time for 
@spmallette for example. In any case this fixes it for me and should be fixing 
for everybody..

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/newkek/incubator-tinkerpop TINKERPOP-1278-imp

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/390.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #390


commit bbdfc0c5583f58355f91202e0e7870a3cb22e4bd
Author: Kevin Gallardo 
Date:   2016-08-25T09:40:01Z

Improved performance on GraphSON 2.0 deserialization.

commit 13c80cb22c4a847079b0b1c81f20e5958ec1f6b3
Author: Kevin Gallardo 
Date:   2016-08-25T13:08:44Z

Fix an issue with Tree deserialization and the type system.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1415) Vertex programs that rely on getting path parameters can't work

[Bryn Cooke (JIRA)]

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

Bryn Cooke commented on TINKERPOP-1415:
---

Closed, but just want to throw in the idea that PathRetractionStrategy could 
pick up the specific variables that are required rather than globally disabling 
path retraction. 

> Vertex programs that rely on getting path parameters can't work
> ---
>
> Key: TINKERPOP-1415
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1415
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>
> Recently some of our vertex programs have started failing.
> They rely of being able to retrieve an element out of the path.
> However, whereas this used to work now the path element isn't there anymore.
> The root cause is that path retraction doesn't know that the vertex program 
> is interested in the path and therefore culls out parameter.
> I can understand why it does this, but there seems to be no way of exposing 
> the vertex program path requirements such that PathRetractionStrategy can 
> pick them up and do the right thing.
> I tried hacking together a solution by making ProgramVertexProgramStep 
> implement Scoping. This did fix the issue, but I am not confident that this 
> is the way to go.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TINKERPOP-1415) Vertex programs that rely on getting path parameters can't work

[Bryn Cooke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryn Cooke resolved TINKERPOP-1415.
---
Resolution: Duplicate

> Vertex programs that rely on getting path parameters can't work
> ---
>
> Key: TINKERPOP-1415
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1415
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>
> Recently some of our vertex programs have started failing.
> They rely of being able to retrieve an element out of the path.
> However, whereas this used to work now the path element isn't there anymore.
> The root cause is that path retraction doesn't know that the vertex program 
> is interested in the path and therefore culls out parameter.
> I can understand why it does this, but there seems to be no way of exposing 
> the vertex program path requirements such that PathRetractionStrategy can 
> pick them up and do the right thing.
> I tried hacking together a solution by making ProgramVertexProgramStep 
> implement Scoping. This did fix the issue, but I am not confident that this 
> is the way to go.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1415) Vertex programs that rely on getting path parameters can't work

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1415:
---

It's all coming back to me know, thanks [~okram].  [~bryncooke] in light of 
TINKERPOP-1280 and in the meantime, the availability of {{withPath}} would you 
be okay with closing this ticket out?

> Vertex programs that rely on getting path parameters can't work
> ---
>
> Key: TINKERPOP-1415
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1415
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>
> Recently some of our vertex programs have started failing.
> They rely of being able to retrieve an element out of the path.
> However, whereas this used to work now the path element isn't there anymore.
> The root cause is that path retraction doesn't know that the vertex program 
> is interested in the path and therefore culls out parameter.
> I can understand why it does this, but there seems to be no way of exposing 
> the vertex program path requirements such that PathRetractionStrategy can 
> pick them up and do the right thing.
> I tried hacking together a solution by making ProgramVertexProgramStep 
> implement Scoping. This did fix the issue, but I am not confident that this 
> is the way to go.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1415) Vertex programs that rely on getting path parameters can't work

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1415:
---

There is a ticket of {{VertexProgram.getRequirements()}} however, in that 
ticket, we note that we are trying to get rid of the concept of 
{{TraversalRequirements}} !! :D... we were going to have 
{{g.withRequirements(...)}} that people could force, but then again, it 
"requirements." Lets see where the {{TraversalRequirements}} goes in 3.3.x and 
if it stays, then we add {{VertexProgram.getRequirements()}}.

> Vertex programs that rely on getting path parameters can't work
> ---
>
> Key: TINKERPOP-1415
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1415
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>
> Recently some of our vertex programs have started failing.
> They rely of being able to retrieve an element out of the path.
> However, whereas this used to work now the path element isn't there anymore.
> The root cause is that path retraction doesn't know that the vertex program 
> is interested in the path and therefore culls out parameter.
> I can understand why it does this, but there seems to be no way of exposing 
> the vertex program path requirements such that PathRetractionStrategy can 
> pick them up and do the right thing.
> I tried hacking together a solution by making ProgramVertexProgramStep 
> implement Scoping. This did fix the issue, but I am not confident that this 
> is the way to go.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] Code Review TINKERPOP-1278: gremlin-python

[Marko Rodriguez]

Hi,

Here is a terminal session showing off some chops.

https://gist.github.com/okram/0d40c78d7df14c0ca3ad8f3f5c547934 


If you know Gremlin, you know Gremlin-Python. 

Marko.

http://markorodriguez.com



> On Aug 24, 2016, at 8:24 PM, Stephen Mallette  wrote:
> 
> We basically have TINKERPOP-1278 ready for review. For those just tuning
> in, that is the gremlin-python branch which can be viewed here:
> 
> https://github.com/apache/tinkerpop/tree/TINKERPOP-1278
> 
> As I mentioned in a separate email, I don't think we should bother trying
> to issue a pull request for this as it is a massive body of work and GitHub
> tools really won't be useful here. Better to just check-out the branch and
> examine what's going on. Let's use this thread to get our standard
> review/vote process done.
> 
> I don't plan on firing up a separate VOTE thread, so feel free to +1 here
> on this one (we'll keep this informal unless someone has some objection).
> I'll be sure to reference this thread in the JIRA issue itself. I'll also
> note that while we typically hold votes open for 72 hours, that won't be
> the case here as this is not a typical vote thread - it is a code review
> and we have no such restrictions on time when it comes to those.
> 
> Note that we are positioning gremlin-python for 3.2.2 and that it is going
> to be considered a bit experimental so that we can get some feedback on
> usage and perhaps root out some bugs in the process.There is still a fair
> bit of work to do to make this package awesome but as of right now, it's
> very usable.
> 
> Feel free to bring up problems you notice, but I think that reviewers
> should consider the big picture of this pull request rather than the minute
> details. Once we get things back on master we can make some adjustments as
> needed, but I think it's basically time to bring that feature branch back
> home and get it merged.
> 
> One of the nice bits that came in recently from Marko to this branch were
> native python Vertex, Edge, etc. classes which lets users work directly
> with graph elements (as opposed to Map). In that way, we get:
> 
 g.V()[0].toList()
> [v[1]]
 g.E()[0].toList()
> [e[7][1-knows->2]]
 g.V().properties('name')[0].toList()
> [vp[name->marko]]
 g.E().properties('weight')[0].toList()
> [p[weight->0.5]]
> 
> eh? eh? nice, right? Note that retrieval of sideEffects is working well now
> too:
> 
 
> g.V().repeat(groupCount('m').by('name').both()).times(10).cap('m').next()
> {u'vadas': 2378L, u'marko': 5740L, u'josh': 5740L, u'lop': 5740L,
> u'ripple': 2378L, u'peter': 2378L}
 t = g.V().repeat(groupCount('m').by('name').both()).times(10).iterate()
 t.side_effects
> sideEffects[size:1]
 t.side_effects.keys()
> set([u'm'])
 t.side_effects['m']
> {u'lop': 5740L, u'marko': 5740L, u'vadas': 2378L, u'ripple': 2378L,
> u'peter': 2378L, u'josh': 5740L}
> 
> I think the interfaces and core classes are feeling pretty solid now for
> both java and python. We have a good body of test around much of this, but
> have only been able to test native python connectivity to Gremlin Server
> stuff manually. We don't have automated tests for that, but there are many
> automated tests that hit the key aspects of the core of all this processing
> so in that sense there is some solid test coverage in place. As of
> yesterday, full integration tests were passing on this branch which
> includes GraphSON 2.0. I don't believe that much was done today that could
> have affected that outcome.
> 
> The documentation has been updated but will likely need some more work. We
> can do a lot of that during code freeze week. Here's some links to the
> newest bits:
> 
> http://tinkerpop.apache.org/docs/3.2.2-SNAPSHOT/reference/#connecting-via-remotegraph
> 
> http://tinkerpop.apache.org/docs/3.2.2-SNAPSHOT/reference/#gremlin-variants
> 
> Marko, please feel free to follow up with finer points that I've missed -
> my mind is a bit spent on things at this point but wanted this email out
> tonight. Anyway, at this point, I'm going to start this off with a +1 and
> say this is ready to merge back to master.