[
https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255392#comment-16255392
]
ASF GitHub Bot commented on TINKERPOP-1834:
-------------------------------------------
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/748
In reviewing this, I think Gremlin Server needs a change. When we submit a
remote traversal. Gremlin Server needs to check for `iterate()` in the bytecode
and actually call `iterate()` rather than `next()` that way the graph instance
gets the right method called on it for any additional optimization that could
occur there. Plus, if the client did call `iterate()` it's better that Gremlin
Server simply return no results - that's a big optimization. I can work on that
change and just commit it to this branch as part of this PR.
> Consider iterate() as a first class step
> ----------------------------------------
>
> Key: TINKERPOP-1834
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1834
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.6
> Reporter: stephen mallette
> Assignee: Marko A. Rodriguez
>
> The {{iterate()}} terminator on a traversal returns no data. It simply
> executes the traversal in full typically for the generation of side-effects.
> Graph providers could optimize a traversal that is iterated should they be
> able to detect that this method is called as they might avoid certain read
> operations if the traversal is explicitly meant to just update the graph.
> A possible solution for this would be some form of direct implementation of
> an explicit {{IterateStep}} which providers could identify. Or perhaps, a
> more generic {{NoOpStep}} would be better where the {{NoOpStep}} would
> basically just be a marker with some meta-data tied to it (i.e. a {{Map}} of
> arbitrary configuration options). In this case, the configuration options
> would simply have an "iterate" value in it which the provider could interpret
> if they could optimize based on that. Other solutions?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
