[
https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260614#comment-16260614
]
ASF GitHub Bot commented on TINKERPOP-1834:
-------------------------------------------
GitHub user okram opened a pull request:
https://github.com/apache/tinkerpop/pull/755
TINKERPOP-1834: Consider iterate() as a first class step
https://issues.apache.org/jira/browse/TINKERPOP-1834
This is a re-issuing of a previously closed commit. In this model, a
`NoneStep` was added as well as a `Traversal.none()`. `Traversal.iterate()`
calls `Traversal.none()` if the traversal has not been fully compiled. The
benefit of this is that `iterate()` will add a full filter and thus, for remote
systems (non-embedded), all data is "iterated" server-side before being sent
back to the client. This is a novel play in that `iterate()`, while being a
terminal step, is now effecting the bytecode representation.
cc/ @BrynCooke
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1834
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/755.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #755
----
commit 2a957bb586263b2dd70b4db36d1b3c6f87d5596f
Author: Marko A. Rodriguez <[email protected]>
Date: 2017-11-21T11:44:32Z
Added NoneStep which simply filter(false). Traversal.none() was added which
appends the NoneStep. Traversal.iterate() was updated such that if the
traversal has not been compiled yet, then Traversal.none() is called to ensure
that a full filter is propagated in the bytecode.
----
> 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)
