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

ASF GitHub Bot commented on TINKERPOP-1834:
-------------------------------------------

Github user dkuppitz commented on the issue:

    https://github.com/apache/tinkerpop/pull/755
  
    That's better.
    
    ```
    [INFO] 
------------------------------------------------------------------------
    [INFO] Reactor Summary:
    [INFO] 
    [INFO] Apache TinkerPop ................................... SUCCESS [01:32 
min]
    [INFO] Apache TinkerPop :: Gremlin Shaded ................. SUCCESS [ 
17.087 s]
    [INFO] Apache TinkerPop :: Gremlin Core ................... SUCCESS [01:37 
min]
    [INFO] Apache TinkerPop :: Gremlin Test ................... SUCCESS [  
8.780 s]
    [INFO] Apache TinkerPop :: TinkerGraph Gremlin ............ SUCCESS [04:34 
min]
    [INFO] Apache TinkerPop :: Gremlin Groovy ................. SUCCESS [03:59 
min]
    [INFO] Apache TinkerPop :: Gremlin Driver ................. SUCCESS [01:44 
min]
    [INFO] Apache TinkerPop :: Neo4j Gremlin .................. SUCCESS [  
1.127 s]
    [INFO] Apache TinkerPop :: Gremlin Server ................. SUCCESS [17:08 
min]
    [INFO] Apache TinkerPop :: Gremlin Python ................. SUCCESS [01:19 
min]
    [INFO] Apache TinkerPop :: Gremlin.Net .................... SUCCESS [ 
12.029 s]
    [INFO] Apache TinkerPop :: Gremlin.Net - Source ........... SUCCESS [01:08 
min]
    [INFO] Apache TinkerPop :: Gremlin.Net - Tests ............ SUCCESS [ 
44.917 s]
    [INFO] Apache TinkerPop :: Hadoop Gremlin ................. SUCCESS [19:17 
min]
    [INFO] Apache TinkerPop :: Spark Gremlin .................. SUCCESS [17:15 
min]
    [INFO] Apache TinkerPop :: Giraph Gremlin ................. SUCCESS [  
01:24 h]
    [INFO] Apache TinkerPop :: Gremlin Console ................ SUCCESS [02:37 
min]
    [INFO] Apache TinkerPop :: Gremlin Archetype .............. SUCCESS [  
0.134 s]
    [INFO] Apache TinkerPop :: Archetype - TinkerGraph ........ SUCCESS [ 
20.920 s]
    [INFO] Apache TinkerPop :: Archetype - Server ............. SUCCESS [ 
15.828 s]
    [INFO] Apache TinkerPop :: Archetype - DSL ................ SUCCESS [  
6.089 s]
    [INFO] Apache TinkerPop :: Gremlin Tools .................. SUCCESS [  
0.306 s]
    [INFO] Apache TinkerPop :: Gremlin Benchmark .............. SUCCESS [  
4.824 s]
    [INFO] Apache TinkerPop :: Gremlin Coverage ............... SUCCESS [  
0.737 s]
    [INFO] Apache TinkerPop :: Gremlin IO Test ................ SUCCESS [  
5.217 s]
    [INFO] 
------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] 
------------------------------------------------------------------------
    [INFO] Total time: 02:39 h
    [INFO] Finished at: 2017-11-28T15:43:00+00:00
    [INFO] Final Memory: 180M/1136M
    [INFO] 
------------------------------------------------------------------------
    ```


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

Reply via email to