[
https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16259315#comment-16259315
]
ASF GitHub Bot commented on TINKERPOP-1834:
-------------------------------------------
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/748
A `cap()` step is a `SupplyBarrierStep` and thus, requires an emission -- a
single emission, but an emission nonetheless. The ultimate solution step has to
a `FilterStep` by nature so it can truly return "nothing." However, we are now
getting into particulars that don't need arguing. The concept is what matters.
Now that I get the problem, you simply don't want to have to "reattach" and
send data back if you don't have to, then the solution is, filter everything as
the last step. That is, have `iterate()` append to the bytecode a "filter all."
Easy. How that is done, just needs some fiddlin' around.
> 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)
