[
https://issues.apache.org/jira/browse/TINKERPOP-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Choi updated TINKERPOP-2042:
-----------------------------------
Description:
_g.E().fold().coalesce(unfold(), g.E())_ is a valid traversal that can be
evaluated if submitted to a gremlin server in String execution mode (i.e., via
console or http). However if the same traversal is submitted as bytecode, the
server throws an error while translating the bytecode back to GLV (perhaps GLV
is not the technically correct term here, I mean when the bytecode is
translated back to gremlin objects in the server's respective language stack).
Stack Trace:
java.lang.IllegalStateException: Could not locate method:
DefaultGraphTraversal.E()
0 = \{StackTraceElement@10575}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:202)"
1 = \{StackTraceElement@10576}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translateObject(JavaTranslator.java:111)"
2 = \{StackTraceElement@10577}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:195)"
3 = \{StackTraceElement@10578}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translate(JavaTranslator.java:87)"
4 = \{StackTraceElement@10579}
"org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:370)"
5 = \{StackTraceElement@10580}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:74)"
6 = \{StackTraceElement@10581}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:49)"
...
This is because E() is not part of GraphTraversal. The commit that introduced
V() into GraphTraversal didn't seem to specify any reasons particularly against
also having E() as part of GraphTraversal:
[https://github.com/apache/tinkerpop/commit/5c5bd06ebbd4ad6781ba46349ebb638f93b4f469].
It'd be a more consistent user experience to also have E() as part of
GraphTraversal so that it can be used mid-traversal similar to V().
Tested on a Java gremlin server, but I suspect this would apply to all other
flavors if GLV spec mandates E() not be part of GraphTraversal.
was:
_g.E().fold().coalesce(unfold(), g.E())_ is a valid traversal that can be
evaluated if submitted to a gremlin server in String execution mode (i.e., via
console or http). However if the same traversal is submitted as bytecode, the
server throws an error while translating the bytecode back to GLV (perhaps GLV
is not the technically correct term here, I mean when the bytecode is
translated back to gremlin objects in the server's respective language stack).
Stack Trace:
0 = \{StackTraceElement@10575}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:202)"
1 = \{StackTraceElement@10576}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translateObject(JavaTranslator.java:111)"
2 = \{StackTraceElement@10577}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:195)"
3 = \{StackTraceElement@10578}
"org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translate(JavaTranslator.java:87)"
4 = \{StackTraceElement@10579}
"org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:370)"
5 = \{StackTraceElement@10580}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:74)"
6 = \{StackTraceElement@10581}
"org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:49)"
...
This is because E() is not part of GraphTraversal. The commit that introduced
V() into GraphTraversal didn't seem to specify any reasons particularly against
also having E() as part of GraphTraversal:
[https://github.com/apache/tinkerpop/commit/5c5bd06ebbd4ad6781ba46349ebb638f93b4f469].
It'd be a more consistent user experience to also have E() as part of
GraphTraversal so that it can be used mid-traversal similar to V().
Tested on a Java gremlin server, but I suspect this would apply to all other
flavors if GLV spec mandates E() not be part of GraphTraversal.
> Bytecode to GLV translation broken for E()
> ------------------------------------------
>
> Key: TINKERPOP-2042
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2042
> Project: TinkerPop
> Issue Type: Bug
> Environment: Java GLV
> Reporter: Daniel Choi
> Priority: Major
>
> _g.E().fold().coalesce(unfold(), g.E())_ is a valid traversal that can be
> evaluated if submitted to a gremlin server in String execution mode (i.e.,
> via console or http). However if the same traversal is submitted as
> bytecode, the server throws an error while translating the bytecode back to
> GLV (perhaps GLV is not the technically correct term here, I mean when the
> bytecode is translated back to gremlin objects in the server's respective
> language stack).
>
> Stack Trace:
> java.lang.IllegalStateException: Could not locate method:
> DefaultGraphTraversal.E()
> 0 = \{StackTraceElement@10575}
> "org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:202)"
> 1 = \{StackTraceElement@10576}
> "org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translateObject(JavaTranslator.java:111)"
> 2 = \{StackTraceElement@10577}
> "org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.invokeMethod(JavaTranslator.java:195)"
> 3 = \{StackTraceElement@10578}
> "org.apache.tinkerpop.gremlin.jsr223.JavaTranslator.translate(JavaTranslator.java:87)"
> 4 = \{StackTraceElement@10579}
> "org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:370)"
> 5 = \{StackTraceElement@10580}
> "org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:74)"
> 6 = \{StackTraceElement@10581}
> "org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:49)"
> ...
>
> This is because E() is not part of GraphTraversal. The commit that
> introduced V() into GraphTraversal didn't seem to specify any reasons
> particularly against also having E() as part of GraphTraversal:
> [https://github.com/apache/tinkerpop/commit/5c5bd06ebbd4ad6781ba46349ebb638f93b4f469].
> It'd be a more consistent user experience to also have E() as part of
> GraphTraversal so that it can be used mid-traversal similar to V().
>
> Tested on a Java gremlin server, but I suspect this would apply to all other
> flavors if GLV spec mandates E() not be part of GraphTraversal.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
