You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Daniel Kuppitz (JIRA)" <ji...@apache.org> on 2018/03/16 15:04:00 UTC

[jira] [Created] (TINKERPOP-1925) Don't apply PathRetractionStrategy recursively

Daniel Kuppitz created TINKERPOP-1925:
-----------------------------------------

             Summary: Don't apply PathRetractionStrategy recursively
                 Key: TINKERPOP-1925
                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1925
             Project: TinkerPop
          Issue Type: Improvement
          Components: process
    Affects Versions: 3.2.7
            Reporter: Daniel Kuppitz


{{PathRetractionStrategy}} should not be applied recursively, if possible. This is considered an anti-pattern and just recently it caused a lot of trouble. This commit fixed the recent issue:

https://github.com/apache/tinkerpop/commit/b8eb8a02f1675a1b22b86ccc54d22453c65f406f

{{PathRetractionStrategy}} collects requirements of child traversals, before other strategies have a chance to mutate them. When other strategies get to the child traversals, mutate them and thus add or remove requirements, a few things can go crazy, especially because traverser requirements get cached when they're first requested.

Since I do not fully understand the {{PathRetractionStrategy}} code, my fix was actually a workaround. As you can see in the commit linked above, I implemented the same anti-pattern in {{SubgraphStrategy}} and {{IncidentToAdjacentStrategy}}; these are the 2 strategies that can potentially change the traverser requirements.

It would be nice to revert these changes and instead make {{PathRetractionStrategy}} work like all others. However, I'm not sure if that's even possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)