[
https://issues.apache.org/jira/browse/TINKERPOP-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-1925.
---------------------------------------
Resolution: Won't Do
I dont think we can implement this easily on 3.4.x and TINKERPOP-1568 for 3.5.0
seems to make this issue not so relevant anymore given the change in strategy
application order. Closing with the idea that this issue isn't worth driving
through 3.4-dev at this point.
> 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
> Assignee: Stephen Mallette
> Priority: Major
>
> {{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
(v8.3.4#803005)
