[jira] [Created] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
Adam Holmberg created TINKERPOP-1474: Summary: API Alignment Between Java Gremlin Graph Structure and GLVs Key: TINKERPOP-1474 URL: https://issues.apache.org/jira/browse/TINKERPOP-1474 Project: TinkerPop Issue Type: Bug Reporter: Adam Holmberg The current Java GraphSON implementation and that in the Python GLV leave some question about what *should* be returned from a simple traversal like `g.V()`. The java implementation presently assumes that properties could be present and returns a DetachedVertex: https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433 The python implementation assumes no such thing and returns something more reminiscent of a ReferenceVertex: https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242 Is the java version overreaching, and should not expect properties unless a step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or should the Python version be expanded? Is there something we can do to establish guidelines for this, and align these APIs? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure
[ https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453271#comment-15453271 ] Adam Holmberg commented on TINKERPOP-1278: -- I see it's already revised, but just to acknowledge the response: I'm +1 on this direction. Thanks for the discussion. > 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 > Fix For: 3.2.2 > > > 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] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure
[ https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449751#comment-15449751 ] Adam Holmberg commented on TINKERPOP-1278: -- I see this is merged now. I wanted to follow up on some comments I had on one commit pre-merge: https://github.com/apache/tinkerpop/commit/6ed7edc0b4ad2abf933e917812d49ad92230c8d1#commitcomment-18473940 Is there still a chance to make this generate more idiomatic Python as suggested in the GLV docs? Was this discussed anywhere else? > 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 > Fix For: 3.2.2 > > > 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)