Details
Description
Right now the RemoteConnection API is this:
public <E> Iterator<Traverser.Admin<E>> submit(final Traversal<?, E> traversal) throws RemoteConnectionException;
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:
public <E> Traversal<?,E> submit(final Traversal<?, E> traversal) throws RemoteConnectionException;
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:
public <E> Iterator<Traverser.Admin<E>> submit(final String alias, final String scriptEngine, final String traversalScript, Object... bindings) throws RemoteConnectionException;
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
Attachments
Issue Links
- is related to
-
TINKERPOP-1278 Implement Gremlin-Python and general purpose language variant test infrastructure
-
- Closed
-