[
https://issues.apache.org/jira/browse/TINKERPOP-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934290#comment-17934290
]
Stephen Mallette commented on TINKERPOP-2968:
---------------------------------------------
Strategies really shouldn't alter query results. In this case, the addition of
a {{barrier(2500)}} from {{LazyBarrierStrategy}} just happens to allow the
query to work because there were less than 2500 traversers. If there were more
it would have failed in similar fashion.
The advanced Gremlin users might have noted that this query would not work as
intended without a {{Barrier}} or {{fold()}} to force all the side-effects to
execute before doing the final {{drop()}}, but I doubt most would catch that.
That said, I think the answer here is:
1. {{LazyBarrierStrategy}} should get restricted for this case and others that
can be identified where it silently changes query results in an unexpected way.
2. Develop a more simplistic case than the one above that demonstrates the
above situation and why a barrier of some sort is necessary. Use that example
to improve the documentation.
3. Develop tests that help better cover 1 and 2.
> Fix DropStep semantics for deleted element referenced by upstream steps
> -----------------------------------------------------------------------
>
> Key: TINKERPOP-2968
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2968
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Reporter: Saikiran Boga
> Priority: Major
>
> This is from a recent user question on StackOverflow here
> [https://stackoverflow.com/questions/76662422/how-does-it-come-that-my-gremlin-query-delivers-two-different-results]
> for difference in behavior when using drop step.
>
> With this preloaded data:
> {code:java}
> g.addV("TopVertex").property('id',
> 4713).property('testProperty1','testProperty1').as('vertex1')
> .addV("SubVertex").property('name','C1').as('C1')
> .addV("SubVertex").property('name','C2').as('C2')
> .addV("SubVertex").property('name','C3').as('C3')
> .addE("splitsInto").from('vertex1').to('C1').property('ordinal',1)
> .addE("splitsInto").from('vertex1').to('C2').property('ordinal',2)
> .addE("splitsInto").from('vertex1').to('C3').property('ordinal',3)
> .addV("TopVertex").property('id',
> 4713).property('testProperty2','testProperty2').as('vertex2')
> .addV("SubVertex").property('name','C4').as('C4')
> .addV("SubVertex").property('name','C5').as('C5')
> .addV("SubVertex").property('name','C6').as('C6')
> .addE("splitsInto").from('vertex2').to('C4').property('ordinal',4)
> .addE("splitsInto").from('vertex2').to('C5').property('ordinal',5)
> .addE("splitsInto").from('vertex2').to('C6').property('ordinal',6) {code}
> And when we run the below query:
> {code:java}
> g.withoutStrategies(LazyBarrierStrategy.class).
> addV("MergedVertex").property('id', 4713).as('mergedVertex').
> V().hasLabel("TopVertex").has('id', 4713).as('oldVertices').
> outE().as('oldEdges').
> inV().as('inVertices').
> select('mergedVertex').
> addE('splitsInto').to('inVertices').as('newEdges').
> sideEffect(select('oldEdges').properties().
> unfold().as('props').
> select('newEdges').
> property(select('props').key(), select('props').value())).
> select('oldVertices').drop() {code}
> When LazyBarrierStrategy is disabled, drop() step at the end here drops
> `oldVertices` one at a time, i.e., no batching before drop() step.
>
> This results in one of the `oldVertices` deleted when it is first
> encountered, along with its edges. But the same vertex or related edges are
> used by subsequent solutions in the same query it no longer exists and the
> query does not work as intended.
>
> With LazyBarrierStrategy enabled, the query adds 6 edges, each with a
> property `ordinal`. But without the strategy, it adds only 2 edges. There is
> a difference in query behavior and is confusing to users.
>
> TinkerPop should define semantics for this case how drop will behave in this
> case and what guarantees a provider should provide to the users. For
> instance, as mentioned in the SO post in Neptune without using an explicit
> barrier the query does not work similar to TinkerPop.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
