[
https://issues.apache.org/jira/browse/TINKERPOP-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239641#comment-17239641
]
Marc de Lignie commented on TINKERPOP-2473:
-------------------------------------------
Another issue with the application of traversal strategies is that a
restricting strategy such a ReadOnlyStrategy can simply be removed remotely
with a withoutStrategies(ReadOnlyStrategy). Although I can imagine cases where
you would allow this on purpose, it clearly was not the intention of the
authors because there even is a gremlin-server-modern-readonly.yaml example
file that suggests that the graph is exposed as readonly. So, I feel there
should be a list of restricting strategies (currently
{color:#008000}"ReadOnlyStrategy"{color},
{color:#008000}"SubgraphStrategy"{color},
{color:#008000}"PartitionStrategy"{color},{color:#008000}"LambdaRestrictionStrategy"{color},
{color:#008000}"EdgeLabelVerificationStrategy"{color}) that cannot be undone.
If admins want to expose a graph with Gremlin Server in both the restricted and
the unrestricted way, they can simply provide two differently named
GraphTraversalSource instances.
I think this is best resolved as part of this issue (TINKERPOP-2473) and
implies some changes in the application logic of the traversal strategies. What
do you think?
The documentation I will push this afternoon as part of TINKERPOP-2389 adds
some description about the application of traversal strategies (but covers the
present situation), please feel free to use it for documentation of the present
issue.
> Allow TraversalStrategy instances to be merged
> ----------------------------------------------
>
> Key: TINKERPOP-2473
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2473
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.4.8
> Reporter: Stephen Mallette
> Priority: Major
>
> Not sure if this is a great idea but it came up as part of TINKERPOP-2389
> where there might be a need to assign both a client-side and server-side
> {{SubgraphStrategy}}. Currently, while not explicit, you can't assign more
> than one strategy of a particular type using {{withStrategies()}}. This task
> would make that explicit and provide a direct way for mergeable strategies to
> be pushed together into one. If we did that it would also simplify
> {{OptionsStrategy}} usage in {{with()}} step which currently finds an
> existing one first if present and then adds to it (otherwise creates it new).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
