Cole-Greer commented on PR #3451: URL: https://github.com/apache/tinkerpop/pull/3451#issuecomment-4656551888
Hi @kartikey321, Thanks for putting this together, I'd love to see if we can start expanding our offerings of GLVs, now that agentic tooling can reduce some of the maintenance burden. I'll leave most of the discussion on finding a home for this work to Stephen's devlist thread (I think this would be a great fit in a revived Tinkubator). I'm curious how you approached the development of the driver, was it derived from one of the existing GLVs or built primarily from spec/documentation? Did you have to hand-code much of it or was AI helpful in accelerating the development? I've taken a quick look at the build and test setup, and there are a few details I wanted to make note of, although it may be best to let the devlist discussion play out for a few more days before making large changes. 1. For the non-Java GLVs, we like to run the build and tests from within Docker to limit the number of runtimes developers need to manage. The [setup from Python](https://github.com/apache/tinkerpop/blob/master/gremlin-python/docker-compose.yml) is a reasonable example to copy from. It's also worth noting how python pulls in the existing server image from `docker/gremlin-test-server/Dockerfile` instead of maintaining a bespoke test server configuration per driver. 2. I noticed that the feature tests are currently extracting the gremlin scripts from the feature test scenarios and feeding them into `Connection.submit()` as strings. That's a good starting place (gets good coverage of the transport and serialization), but ideally we want the feature tests to generate GraphTraversal's and execute those as that is most aligned with how users are expected to use the drivers. Our setup for doing such is a bit complex as we do not have a gremlin parser in most languages. The current infrastructure is we maintain [translators in gremlin-core](https://github.com/apache/tinkerpop/tree/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/language/translator), and these translators get invoked by [a groovy script](https://github.com/apache/tinkerpop/blob/master/gremlin-python/build/generate.groovy) in each GLV to parse and translate [all of the scenarios into the native language variant](https://github.com/apache/tinkerpop/blob/master/gremlin-p ython/src/main/python/tests/feature/gremlin.py). I'd be happy to help with this setup if it proves troublesome. 3. Regarding your failing feature tests: a. g_injectXnull_nullX_conjoinXplusX (`g.inject([null,null]).conjoin("+")`) I wonder if something may be going on with escaping the `"+"` argument or handling of the empty string response. This scenario is expected to work in the server. b. g_withSackX2147483647iX_injectX0_5fX_sackXdivX_sack, it's worth double checking the client isn't doing any unexpected lossy type conversions, but this is likely a case where it's fine to add a little tolerance to floating point equality checks in the test suite. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
