[
https://issues.apache.org/jira/browse/TINKERPOP-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667615#comment-15667615
]
ASF GitHub Bot commented on TINKERPOP-1502:
-------------------------------------------
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/495
Yea, looks better now. Not sure if we should really keep all the steps in
`g.V(1).outE('knows').hasLabel('created').more().bla()`. It's like the Java
compiler would keep stuff within a `if (false) { ... }` block. The static
analysis already tells us, that nothing will make it through the filter.
You already treat this particular case in a dedicated code block, why not
remove everything that comes after it and append a `.not(identity())`?
> Chained has()-steps should simply left-append HasContainers in Gremlin-Java.
> ----------------------------------------------------------------------------
>
> Key: TINKERPOP-1502
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1502
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.2
> Reporter: Marko A. Rodriguez
>
> In Gremlin-Java, {{g.V().has(a).has(b).has(c).out()}} is originally
> represented as {{[GraphStep,HasStep(a),HasStep(b),HasStep(c),VertexStep]}}.
> Ultimately, {{InlineFilterStrategy}} or most provider strategies will turn
> such {{HasStep}}-chains into {{[GraphStep,HasStep(a,b,c),VertexStep]}}. That
> is, strategies fold {{has()}}-steps "left" and delete "right" {{has()}}-steps
> and left propagates their labels (i.e. clock cycles). I think that
> {{GraphTraversal}} should simply do this:
> {code}
> public GraphTraversal has(whateves) {
> if(this.getEndStep() instanceof HasStep)
> this.getEndSte().addHasContainer(new HasContainer(whateves))
> else
> this.addStep(new HasStep(new HasContainer(whateves)));
> this.bytecode.addStep("has",whateves);
> return this;
> }
> {code}
> In essence, a "write time" optimization can be done. Given that chains of
> {{has()}}'s is super common, this can save significant clock-cycles in the
> long run of a production application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
