[
https://issues.apache.org/jira/browse/TINKERPOP-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257010#comment-17257010
]
Stephen Mallette commented on TINKERPOP-2473:
---------------------------------------------
Submitted a PR to prevent multiple strategies of the same type from being
assigned. That wasn't too hard. As for preventing ones from being removed, that
issue has less of an easy fix to implement. I dont think that will every work
for scripts with just API changes. There would always have to be some kind of
sandboxing involved as scripts don't respect variable scopes. For bytecode API
changes could try to simplify what is already possible with existing APIs. With
existing APIs you could supply your own {{TraversalStrategies}} implementation
to {{GraphTraversalSource}}. That custom implementation could then be
preconfigured with strategies and block the addition/removal of others. I'm
somewhat hesitant to make that easier though because it will expose those
features to both the server and client sides when this is much more of a server
side issue only. Anyway, I'd prefer not to try to do any of that on this issue
as this one is already pretty well defined and settled.
> 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)
