[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/546


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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/546
  
I just tested the `PathRetractionStrategy` code in the GraphActors branch 
and the `akka-gremlin/` test suite passes.

*** Sidenote: can you finalize your variables if possible?

VOTE +1.


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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

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

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

Github user twilmes commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/546#discussion_r98270533
  
--- Diff: 
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/PathRetractionStrategyTest.java
 ---
@@ -37,14 +37,8 @@
 import java.util.List;
 import java.util.Set;
 
-import static org.apache.tinkerpop.gremlin.process.traversal.P.eq;
-import static org.apache.tinkerpop.gremlin.process.traversal.P.gte;
-import static org.apache.tinkerpop.gremlin.process.traversal.P.neq;
-import static 
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__.as;
-import static 
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__.limit;
-import static 
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__.out;
-import static 
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__.select;
-import static 
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__.values;
+import static org.apache.tinkerpop.gremlin.process.traversal.P.*;
--- End diff --

Installed a new IDE and never turned wildcard imports off.  Good catch!


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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/546
  
VOTE: +1


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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/546
  
This also fixes 
[TINKERPOP-1597](https://issues.apache.org/jira/browse/TINKERPOP-1597), but the 
test I've added can only be included in the 3.3.x line, right?


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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

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

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

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/546
  
Made a small update to remove a dependency between `PathRetractionStrategy` 
and `MatchPredicateStrategy`.  I should also note, this PR addresses 
TINKERPOP-1597.  TINKERPOP-1597 was entered against 3.3.0 and a small change to 
one of `PathRetractionStrategy` test cases will be required when tp32 is merged 
into master due to the differing implementation of the `optional`.

`docker/build.sh -t -i` ran last night with success with this last commit.

VOTE: +1


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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[ASF GitHub Bot (JIRA)]

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

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

GitHub user twilmes opened a pull request:

https://github.com/apache/tinkerpop/pull/546

TINKERPOP-1583: PathRetractionStrategy retracts keys that are actually 
needed

`PathRetractionStrategy` was not pushing `keepLabels` down into sibling 
traversals of children with label requirements.  Labels were also not being 
pushed down into `TraversalParents` earlier in the traversal.

@okram I saw you had a `PathRetractionStrategy` issue while doing some 
other work.  Do you have a traversal you were getting a failure on?  I can make 
sure this fixes it and adds a test case if so.

`./docker/build.sh -t -i` success
```
[INFO] Apache TinkerPop .. SUCCESS [30.949s]
[INFO] Apache TinkerPop :: Gremlin Shaded  SUCCESS [9.462s]
[INFO] Apache TinkerPop :: Gremlin Core .. SUCCESS [56.670s]
[INFO] Apache TinkerPop :: Gremlin Test .. SUCCESS [4.887s]
[INFO] Apache TinkerPop :: Gremlin Groovy  SUCCESS 
[2:09.535s]
[INFO] Apache TinkerPop :: Gremlin Groovy Test ... SUCCESS [4.935s]
[INFO] Apache TinkerPop :: TinkerGraph Gremlin ... SUCCESS 
[3:32.013s]
[INFO] Apache TinkerPop :: Gremlin Benchmark . SUCCESS 
[32:23.091s]
[INFO] Apache TinkerPop :: Gremlin Driver  SUCCESS 
[15:56.763s]
[INFO] Apache TinkerPop :: Neo4j Gremlin . SUCCESS 
[15:53.728s]
[INFO] Apache TinkerPop :: Gremlin Server  SUCCESS 
[30:15.950s]
[INFO] Apache TinkerPop :: Gremlin Python  SUCCESS 
[32:02.364s]
[INFO] Apache TinkerPop :: Hadoop Gremlin  SUCCESS 
[22:03.412s]
[INFO] Apache TinkerPop :: Spark Gremlin . SUCCESS 
[52:17.578s]
[INFO] Apache TinkerPop :: Giraph Gremlin  SUCCESS 
[2:52:20.792s]
[INFO] Apache TinkerPop :: Gremlin Console ... SUCCESS 
[32:59.765s]
[INFO] Apache TinkerPop :: Gremlin Archetype . SUCCESS [0.085s]
[INFO] Apache TinkerPop :: Archetype - TinkerGraph ... SUCCESS 
[16:05.156s]
[INFO] Apache TinkerPop :: Archetype - Server  SUCCESS [10.964s]
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

```

VOTE: +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1583

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/546.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #546


commit da762dfee9b0ed05fd1185d80403e1be41873b58
Author: Ted Wilmes 
Date:   2017-01-24T20:57:07Z

Fixed a bug where keepLabels were not being pushed down into child 
traversals by PathRetractionStrategy.




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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1583:
---

You know you can do {{g = g.withoutStrategy(PathRetractionsStrategy.class)}} to 
get around the bug until its fixed.

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

[jira] [Commented] (TINKERPOP-1583) PathRetractionStrategy retracts keys that are actually needed

[Ted Wilmes (JIRA)]

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

Ted Wilmes commented on TINKERPOP-1583:
---

Thanks for reporting this [~gereedy].  I'll take a look.

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