Saikiran Boga created TINKERPOP-2968:
----------------------------------------
Summary: 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
Reporter: Saikiran Boga
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)
