[TINKERPOP-2968] Fix DropStep semantics for deleted element referenced by upstream steps

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: process
• Assignee: Unassigned
• Reporter: Saikiran Boga
• Created: 14/Jul/23 07:27
• Updated: 14/Jul/23 07:28

Description

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:

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) 

And when we run the below query:

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() 

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.