[
https://issues.apache.org/jira/browse/TINKERPOP-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621285#comment-16621285
]
stephen mallette commented on TINKERPOP-2042:
---------------------------------------------
I don't remember why we didn't do a mid-traversal {{E()}} but I suspect that
there was an actual reason when the design decision was made. Note that you can
quite easily work around this issue with the following:
{code}
g.E().fold().coalesce(unfold(), V().outE())
{code}
I think that these days more and more people around TinkerPop are seeing
{{E()}} as more of anti-pattern, as starting a traversal from an {{Edge}} is
probably "bad". I'd imagine that future versions of Gremlin will first
deprecate it and then eventually drop it. I'd be against propagating it further
at this point.
> 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)
