[
https://issues.apache.org/jira/browse/TINKERPOP-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saikiran Boga updated TINKERPOP-2968:
-------------------------------------
Component/s: process
> 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)
