[
https://issues.apache.org/jira/browse/TINKERPOP-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16630859#comment-16630859
]
stephen mallette commented on TINKERPOP-2050:
---------------------------------------------
I see where you're coming from. It's convenient to have a way to look at the
groovy representation of a traversal. However, gremlin-core doesn't depend on
Groovy (it's the other way around) so the {{GroovyTranslator}} wouldn't be
available to use that way. I also think we want to keep "groovy" away from
Gremlin. Because of it's earlier roots in Groovy in 1.x and 2.x and the fact
that we have a Gremlin Groovy Console and that a lot of our docs have a Groovy
style to them, there is this notion that Gremlin needs Groovy to work.
Obviously, that's not the case, but the fewer things we do to enforce the
connection there the better imo. There is also the technical problem the
{{Traversal}} contains lambdas that aren't properly formed to be converted to
groovy scripts...it would be able to be applied consistently as I suppose we'd
have to throw an exception which stinks.
I wonder if it would be cool if the Console could read bytecode from a command
like:
{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> :bytecode translate g [[], [V(), out(knows), out(created)]]
==> g.V().out('knows').out('created')
gremlin> :bytecode eval g [[], [V(), out(knows), out(created)]]
==>v[5]
==>v[3]
{code}
Might be a helpful debugging tool in some cases.
> Add a .toGremlinGroovyString() method to Traversal class
> --------------------------------------------------------
>
> Key: TINKERPOP-2050
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2050
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.9
> Reporter: Jim Hatcher
> Priority: Minor
>
> I am working on a project where there is Java code being written to
> dynamically generate a Traversal based on a request coming in to an API. You
> can think of this as a "Traversal Builder."
> The code looks something like this:
> {code:java}
> Traversal<Vertex, Vertex> traversal = g.V();
> if (request.searchByAddress == true) {
> traversal.hasLabel("address");
> if (request.address.addressLine1 != null){
> traversal.has("address_line_1", request.address.addressLine1)
> }
> }
> etc.
> {code}
> When that code is being debugged, a traversal.toString() is run on the
> traversal to see the ouptut. This output is Gremlin bytecode.
> It would be nice to have a way to easily see the Gremlin Groovy that was
> built so that you could take the Groovy, drop it into Studio, make sure it
> runs, run a profile() on it, and make sure it's efficient.
> I figured out that you can do this by running this code:
> {code:java}
> private String toGremlinGroovyString(Traversal traversal){
> if (traversal == null){
> return null;
> }
> Bytecode bc = traversal.asAdmin().getBytecode();
> return GroovyTranslator.of("g").translate(bc);
> }
> {code}
> I think it would be nice to add that as a method on the Traversal class so
> that it could be used by driver users more easily.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
