[ 
https://issues.apache.org/jira/browse/TINKERPOP-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839856#comment-15839856
 ] 

ASF GitHub Bot commented on TINKERPOP-1583:
-------------------------------------------

Github user twilmes commented on the issue:

    https://github.com/apache/tinkerpop/pull/546
  
    It looks like when I run this against tp32 without 
`MatchPredicateStrategy`, the `a` and `b` keys are missing from the results.  I 
think I figured out what the issue is.  Without `MatchPredicateStrategy`, the 
wheres are not integrated into the `MatchStep` so `PathRetractionStrategy` sees 
that `a` and `b` are not referenced after the match so they are dropped.  I'll 
make an update so that if this pattern is seen, the match start and end labels 
will be preserved in the same manner as they would be with a traversal where 
the `MatchStep` was the terminating step. 


> PathRetractionStrategy retracts keys that are actually needed
> -------------------------------------------------------------
>
>                 Key: TINKERPOP-1583
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1583
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: process
>    Affects Versions: 3.2.3
>            Reporter: Geoff Reedy
>            Assignee: Ted Wilmes
>
> We've seen this specifically for labels used in the until modulator of repeat 
> but I suspect it happens for other modulators as well. Here's a test case:
> {code}
> graph = TinkerGraph.open()
> g = graph.traversal()
> g.addV().as("first").repeat(addE("next").to(addV()).inV()).times(5).addE("next").to(select("first")).iterate()
> g.V().limit(1).as('z').out().repeat(store('seen').out().where(without('seen'))).until(where(eq('z')))
> {code}
> complains there is no z-key
> I tired to fix it myself and submit a pull request but I found the 
> implementation of PathRetractionStrategy confusing.
> One thing I noticed is that it seems the set of labels a step needs present 
> in order to work properly is determined external to the steps and that code 
> includes a lot of type-tests. If that logic were pushed down into the step 
> implementations I think fixing the repeat case would be easier and it would 
> be possible for extension steps to work properly with this strategy 
> (currently it seems they can't because of the closed-world assumption 
> inherent in the type-casing).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to