Uploaded image for project: 'TinkerPop'
  1. TinkerPop
  2. TINKERPOP-1278

Implement Gremlin-Python and general purpose language variant test infrastructure

VotersStop watchingWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.2.0-incubating
    • Fix Version/s: 3.2.2
    • Component/s: python
    • Labels:
      None

      Description

      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:

      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.

      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
      

      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.).

      g.V.out_e("knows") // returns a Ruby iterator
      

      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.

      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
      

      Thus, the testing data flow would be:

      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 
      

        Attachments

        Issue Links

          Activity

            People

            • Assignee:
              okram Marko A. Rodriguez
              Reporter:
              okram Marko A. Rodriguez

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment