[
https://issues.apache.org/jira/browse/TINKERPOP-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253718#comment-16253718
]
ASF GitHub Bot commented on TINKERPOP-1834:
-------------------------------------------
GitHub user okram opened a pull request:
https://github.com/apache/tinkerpop/pull/748
TINKERPOP-1834: Consider iterate() as a first class step
https://issues.apache.org/jira/browse/TINKERPOP-1834
When a user triggers a "terminal method" (e.g. `toList()`, `toSet()`,
`iterate()`), that method is now appended to the traversal's `Bytecode`. This
allows providers to know what the user's intention is for the results of the
traversal. This can allow them to make internal optimizations about how to
execute the traversal. The drawback of this is that `Translators` need to know
about which steps are "terminal" and to avoid applying them during translation.
To make this easy, `Translator.TERMINAL_STEPS` is a `public static final` field
to allow easy introspection.
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/748.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 #748
----
commit 3adfe7ec66d8cf24f3e8090ffe8dd557600b5b6c
Author: Marko A. Rodriguez <[email protected]>
Date: 2017-11-15T16:11:26Z
Added terminal method to the Traversal bytecode so providers know what the
user used to trigger the evaluation.
----
> 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)
