[ https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260570#comment-16260570 ]
ASF GitHub Bot commented on TINKERPOP-1834: ------------------------------------------- Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/748 Closing. Going to provide a simpler solution. > 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)