You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Marko A. Rodriguez (JIRA)" <ji...@apache.org> on 2016/04/27 18:16:12 UTC
[jira] [Created] (TINKERPOP-1278) Support at least 3 Gremlin
language variants.
Marko A. Rodriguez created TINKERPOP-1278:
---------------------------------------------
Summary: Support at least 3 Gremlin language variants.
Key: TINKERPOP-1278
URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
Project: TinkerPop
Issue Type: Improvement
Affects Versions: 3.2.0-incubating
Reporter: 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)