[
https://issues.apache.org/jira/browse/TINKERPOP-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838174#comment-15838174
]
ASF GitHub Bot commented on TINKERPOP-1583:
-------------------------------------------
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/546
So the problem I was having was related to the interplay between
`PathRetractionStrategy` and `MatchPredicateStrategy`. You can't have
`PathRetractionStrategy` without `MatchPredicateStrategy`.
The test that fails is:
```
g.V().match(
as("a").in("sungBy").as("b"),
as("a").in("writtenBy").as("c"),
as("b").out("writtenBy").as("d"))
.where(as("c").out("sungBy").as("d"))
.where(as("d").has("name", "Garcia"));
```
If I take out `MatchPredicateStrategy` in the TinkerPop computer suite and
only have `PathRetractionStrategy`, the test fails.
If you could figure out how to make it so this dependency doesn't exist,
that would be great. Again, this is a `GraphComputer` execution (and it also
happens with `GraphActors`).
> 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)
