As we look to build out GLVs and expand Gremlin into other programming
languages, one of the important aspects of doing this should be to consider
consistency across GLVs. We should try to prevent capabilities of Java from
being lost in Python, JS, etc.
As we look at both RemoteGraph in Java and gremlin-python we find that
there is no way to get traversal side-effects. If you write a Traversal and
want side-effects from it, you have to write your traversal to return them
so that it comes back as part of the result set. Since RemoteGraph and
gremlin-python don't really allow you to directly "submit a script" it's
not as though you can execute a traversal once for both the result and the
side-effect and package them together in a single request as you might do
with a simple script request:
$ curl -X POST -d
"{\"gremlin\":\"t=g.V(1).values('name').aggregate('x');[v:t.toList(),se:t.getSideEffects().get('x')]\"}"
http://localhost:8182
{"requestId":"3d3258b2-e421-459a-bf53-ea1e58ece4aa","status":{"message":"","code":200,"attributes":{}},"result":{"data":[{"v":["marko"]},{"se":["marko"]}],"meta":{}}}
I'm thinking that we could alter things in a non-breaking way to allow
optional return of side-effect data so that there is a way to have this all
streamed back without the need for the little workaround I just
demonstrated. For REST I think we could just include a sideEffect request
parameter that allowed for a list of side-effect keys to return. Perhaps
the a "*" could indicate that all should be returned. the side-effects
could be serialized into a key sibling to "data" called "sideEffect".
I think a similar approach could be used for websockets and NIO where we
could amend the protocol to accept that sideEffect parameter. We would
first stream results (marked with meta data to specify a "result") and then
stream side effects (again marked with meta data as such).
I considered caching the Traversal instances so that a future request could
get the side effects, but for a variety of reasons I abandoned that (the
cache meant more heap and trying to get the right balance, new transactions
would have to be opened if the side-effect contained graph elements, etc.)
I like the approach of just maintaining our single request-response model
with the changes I proposed above.It seems to provide the least impact with
no new dependencies, is backward compatible and could be completely
optional to RemoteConnections.
