[jira] [Commented] (TINKERPOP-1834) Consider iterate() as a first class step

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253501#comment-16253501 ] 

Marko A. Rodriguez commented on TINKERPOP-1834:
-----------------------------------------------

The other solution is to create no step at all, but simple append {{iterate}} as a bytecode operation. This way, the provider can simply {{tail()}} the bytecode to see what the method was that the user used to "trigger" the traversal. What is nice about this model is that there isn't an extra step for no reason. However, what is bad, is that then the {{Bytecode}} translators have to know about {{iterate}} and "do nothing".

> 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)