[
https://issues.apache.org/jira/browse/TINKERPOP-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717108#comment-17717108
]
Stephen Mallette commented on TINKERPOP-2933:
---------------------------------------------
{{LazyBarrierStrategy}} is usually responsible for injecting the {{barrier()}}:
{code}
gremlin> g.V().out('el0','el1').not(__.has('vp1', lt(0.30755568))).explain()
==>Traversal Explanation
======================================================================================================================================================================
Original Traversal [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
ConnectiveStrategy [D] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
IdentityRemovalStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
MatchPredicateStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
FilterRankingStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
InlineFilterStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
RepeatUnrollStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
PathRetractionStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
ByModulatorOptimizationStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
EarlyLimitStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
CountStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NotStep([HasStep([vp1.lt(0.30755568)])])]
LazyBarrierStrategy [O] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NoOpBarrierStep(2500),
NotStep([HasStep([vp1.lt(0.30755568)])])]
TinkerGraphCountStrategy [P] [GraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NoOpBarrierStep(2500),
NotStep([HasStep([vp1.lt(0.30755568)])])]
TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NoOpBarrierStep(2500),
NotStep([HasStep([vp1.lt(0.30755568)])])]
ProfileStrategy [F] [TinkerGraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NoOpBarrierStep(2500),
NotStep([HasStep([vp1.lt(0.30755568)])])]
StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NoOpBarrierStep(2500),
NotStep([HasStep([vp1.lt(0.30755568)])])]
Final Traversal [TinkerGraphStep(vertex,[]),
VertexStep(OUT,[el0, el1],vertex), NoOpBarrierStep(2500),
NotStep([HasStep([vp1.lt(0.30755568)])])]
{code}
> LazyBarrierStrategy affects the output order of query result
> ------------------------------------------------------------
>
> Key: TINKERPOP-2933
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2933
> Project: TinkerPop
> Issue Type: Bug
> Reporter: Lei Tang
> Priority: Major
>
> I find that when I remove `LazyBarrierStrategy`, sometimes the output order
> of query result can be changed. I don't know whether it is a correct
> behavior, but it sometimes can affect the query result, e.g., a `range()` or
> `limit()` in a query.
> For example, I can get the consistent result with the following queries.
> {code:java}
> gremlin> :>
> g.withoutStrategies(LazyBarrierStrategy).V().out('el0','el1').has('vp1',
> lt(0.30755568))
> ==>v[98]
> ==>v[14]
> ==>v[94]
> gremlin> :> g.V().out('el0','el1').has('vp1', lt(0.30755568))
> ==>v[98]
> ==>v[14]
> ==>v[94]
> {code}
> However, I retrieved a different order of results with the following two
> queries. I think they should also execute the same query results, as well as
> the same order.
> {code:java}
> gremlin> :> g.V().out('el0','el1').not(__.has('vp1', lt(0.30755568)))
> ==>v[78]
> ==>v[35]
> ==>v[103]
> ==>v[103]
> ==>v[80]
> ==>v[80]
> ==>v[50]
> gremlin> :>
> g.withoutStrategies(LazyBarrierStrategy).V().out('el0','el1').not(__.has('vp1',
> lt(0.30755568)))
> ==>v[78]
> ==>v[35]
> ==>v[103]
> ==>v[80]
> ==>v[103]
> ==>v[80]
> ==>v[50]
> {code}
> Thus, if I have some other operations after it, I will get different query
> results.
> {code:java}
> gremlin> :>
> g.withoutStrategies(LazyBarrierStrategy).V().out('el0','el1').not(__.has('vp1',
> lt(0.30755568))).tail(3)
> ==>v[103]
> ==>v[80]
> ==>v[50]
> gremlin> :> g.V().out('el0','el1').not(__.has('vp1', lt(0.30755568))).tail(3)
> ==>v[80]
> ==>v[80]
> ==>v[50]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
