You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by FlorianHockmann <gi...@git.apache.org> on 2017/10/18 16:07:15 UTC

[GitHub] tinkerpop issue #712: TINKERPOP-1752: Gremlin.Net: Generate completely type-...

Github user FlorianHockmann commented on the issue:

    https://github.com/apache/tinkerpop/pull/712
  
    I finally found some time to work on this again and fixed the issues mentioned by @jorgebay. However, I left the `Bindings` implementation unchanged despite the problems with concurrent access as it seems to be still the best solution. (I'm of course open for suggestions on how this can be improved.)
    
    I also noticed that my changes broke the `WithoutStrategies` source step as that now correctly expects to get the `Types` of the Strategies to exclude for which Gremlin.Net had no serializer. So I added a serializer that works basically like the respective one in gremlin-python as it also simply creates an object of the `Type` and then this object will be serialized as before. A unit test ensures that all Strategies have a parameterless constructor as we can't serialize their `Type` otherwise.
    Honestly, I was a bit surprised that I had to serialize `Types` by serializing an empty object of that `Type` although the IO docs show that the GraphSON type `g:Class` [can be serialized like this](http://tinkerpop.apache.org/docs/3.3.0/dev/io/#_class):
    ```json
    {
      "@type" : "g:Class",
      "@value" : "java.io.File"
    }
    ```
    but the Gremlin Server couldn't deserialize the Strategy class when I serialized it like this. So is the documentation wrong here? @spmallette: Could you clarify my confusion here?
    Also the IO docs don't mention how `TraversalStrategies` are serialized in general. Should we add that?
    
    The build is currently failing, but that seems to be caused by travis-ci/travis-ci#8607. I built Gremlin.Net locally and executed the tests without any problems.
    
    BTW: Would it make sense to create a separate pull request for `master` or can we simply execute `generate.groovy` later when this is merged from `tp32` into `master`?


---