If you really want to have your result and your side-effects returned by a
single request, you could do something like this:
gremlin>
g.V(1,2,4).aggregate("names").by("name").aggregate("ages").by("age")*.fold().as("data").select("data",
"names", "ages")*
==>[data:[v[1], v[2], v[4]], names:[marko, vadas, josh], ages:[29, 27, 32]]
gremlin>
g.V(1,2,4).aggregate("names").by("name").aggregate("ages").by("age")*.fold().project("data",
"se").by().by(cap("names","ages"))*
==>[data:[v[1], v[2], v[4]], se:[names:[marko, vadas, josh], ages:[29, 27,
32]]]
gremlin> g.V(1,2,4).aggregate("names").by("name")*.fold().project("data",
"se").by().by(cap("names"))*
==>[data:[v[1], v[2], v[4]], se:[marko, vadas, josh]]
I'm not saying it would be bad to have Gremlin Server handle that for you,
just wanted to show that it's actually pretty easy to get the data and the
side-effects without using the traversal admin methods (hence it should
work for all GLVs).
Cheers,
Daniel
On Thu, Jul 21, 2016 at 4:51 PM, Stephen Mallette <spmalle...@gmail.com>
wrote:
> 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.
>
