Marko A. Rodriguez created TINKERPOP-1347:
---------------------------------------------
Summary: RemoteConnection needs to provide TraversalSideEffects.
Key: TINKERPOP-1347
URL: https://issues.apache.org/jira/browse/TINKERPOP-1347
Project: TinkerPop
Issue Type: Improvement
Components: driver, process, server
Affects Versions: 3.2.0-incubating
Reporter: Marko A. Rodriguez
Right now the {{RemoteConnection}} API is this:
{code}
public <E> Iterator<Traverser.Admin<E>> submit(final Traversal<?, E> traversal)
throws RemoteConnectionException;
{code}
This is bad because a result set is not just an iterator of traversers, it is
also the sideEffects. I just hit a big snag in {{gremlin-variants}} when not
using TinkerGraph and thus, not everything in the same JVM.
I think we should do one of two things:
{code}
public <E> Traversal<?,E> submit(final Traversal<?, E> traversal) throws
RemoteConnectionException;
{code}
In essence, a traversal goes out an then a traversal comes back and that
traversal has an end step iterator of traversers as well as traversal
side-effects. Moreover, that returned {{Traversal}} could be like
{{RemoteTraversal}} and when {{getSideEffects()}} is called, the sideEffects
are lazily fetched ....
We will have the same problem when we extend {{RemoteConnection}} with:
{code}
public <E> Iterator<Traverser.Admin<E>> submit(final String alias, final String
scriptEngine, final String traversalScript, Object... bindings) throws
RemoteConnectionException;
{code}
I sort of like the concept of {{RemoteTraversal}} as it allows us to not only
{{getSideEffects()}}, but also {{toString()}}, etc. A remote traversal can
offer more control than just {{Iterator}}.
cc/ [~spmallette]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
