Hello,
> I see, and how would a traversal like g.V().repeat(out()).times(4) look
> like with the Barrier? Where does the step go?
It would go right before repeat(). However, it would not be something explicit,
but a strategy would insert it. Meaning, there wouldn't be a "forceFeed()"
method in GraphTraversal.
> Wouldn't it be simpler and more standard with the rest of gremlin if the
> inner traversals acted by default in a global scope fashion?
No. Think about something like:
select("a").by("name")
// where by("name") is shorthand for by(values("name")).
You would get a list of the names for all things if the by-traversal was a
global child. This is why its important that it is local -- for every incoming
traverser, get JUST that traverser's name value.
> Anyone needing
> a local behavior could add a LocalStep per his needs. Why do Repeat and
> Coalesce include Local features in addition to their main purpose?
I don't know much about CoalesceStep as I didn't write it, but for RepeatStep,
the local children are the "until" and "emit" checkers you use to see if the
traverser should break out of the loop. The global child is the actual repeated
traversal and since RepeatStep can just send a traverser down it and "not care"
about it again, its a global child. Its RepeatEndStep that does the caring :).
HTH,
Marko.
> On יום ו׳, 14 באוג׳ 2015 at 17:10 Marko A. Rodriguez (JIRA) <[email protected]>
> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/TINKERPOP3-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697075#comment-14697075
>> ]
>>
>> Marko A. Rodriguez commented on TINKERPOP3-702:
>> -----------------------------------------------
>>
>> It would look like this:
>>
>> {code}
>> public class ForceFeedStep extends AbstractStep {
>>
>> public Traverser processNextStarts() {
>> while(starts.hasNext()) {
>> this.getNextStep().add(start.next())
>> }
>> return EmptyTraverser.instance();
>> }
>> }
>> {code}
>>
>> A {{maxFeed}} int can be provided in the {{while()}} predicate so you
>> don't always fully drain the header pipeline (and thus, control memory).
>>
>>
>>> Buffer input to inner traversals
>>> --------------------------------
>>>
>>> Key: TINKERPOP3-702
>>> URL:
>> https://issues.apache.org/jira/browse/TINKERPOP3-702
>>> Project: TinkerPop 3
>>> Issue Type: Improvement
>>> Components: process
>>> Reporter: Ran Magen
>>> Assignee: Marko A. Rodriguez
>>> Fix For: 3.0.0-incubating
>>>
>>>
>>> In elastic-gremlin we implement an optimized VertexStep. Part of its job
>> is to batch/buffer/bulk different traversers and query them together
>> in-order to minizmize the number of queries.
>>> You can see the implementation here:
>> https://github.com/rmagen/elastic-gremlin/blob/master/src/main/java/org/elasticgremlin/process/optimize/ElasticVertexStep.java#L36
>>> This works great in regular traversals, the "starts" iterator returns as
>> many traversers as the previous step gave out.
>>> But when the step is in an innerTraversal (e.g.
>> g.V().repeat(__.out()).times(8)), the "starts" iterator only returns one
>> traverser, and will return the next traverser only in the next call to
>> processNextStart. Thus, there is no way to run a bulk query.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
