lyndonbauto opened a new pull request #1594:
URL: https://github.com/apache/tinkerpop/pull/1594


   # What This Pull Request Contains
   This has the changes for Milestone 1 through 4 of the gremlin-go driver. The 
expectation is that this driver, though not fully featured, will work for 
almost all use cases.
   
   Users should be able to use the driver like any other GLV, though there are 
some advanced features missing (and it has not been optimized with connection 
pooling yet).
   
   # Cucumber Test Suite Considerations
   We have all tests passing in the Cucumber test suite, have integrated the 
driver into the TinkerPop build infrastructure and have the driver ready for an 
actual release.
   
   There has been some minor changes since the Cucumber test suite was last 
run, but I will re-run it and will update the PR with the result as we expect 
100% pass rate there.
   
   # Shoutout to Persons Involved
   I would like to thank @xiazcy, @simonz-bq, @L0Lmaker, @vkagamlyk, 
@divijvaidya, @krlawrence and @spmallette for continued work they have all been 
putting into this either through implementing features or through code reviews.
   
   # Outstanding Items from Prior Review
   I wanted to get a PR up against 3.5-dev sooner than later with the impeding 
code freeze, so with that in mind I left a couple comments open from the past 
PR, which I will be addressing shortly. The comments are from @divijvaidya, and 
are follows:
   
   > 1. For Client.Close() ===> Please document whether this API is idempotent 
or not. Ideally, a close API call should be idempotent. You can achieve this by 
adding a lifecycle state variable with client which goes from INITIALIZED -> 
CLOSING -> CLOSED. If close() API is called when the client is not in 
INITIALIZED state, then it should be a no-op.
   > 2. Please log errors at error level logging before passing the error to 
the user application at all public interfaces such as NewClient or 
client.submit().
   > 3. We are missing integration tests against the server (unless I missed 
something), which can validate the client behaviour in scenario such as:
   >    1. server initiated abrupt WS connection disconnect
   >    2. websocket handshake times out with the server
   >    3. server disconnects a connection but client sends a query on that 
connection afterwards etc.
   > 4. Please add a test which validates that all go routines are destroyed on 
client close


-- 
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: commits-unsubscr...@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to