[
https://issues.apache.org/jira/browse/TINKERPOP-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190291#comment-17190291
]
Kelvin R. Lawrence commented on TINKERPOP-2414:
-----------------------------------------------
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
> Dynamic options for all steps
> -----------------------------
>
> Key: TINKERPOP-2414
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2414
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.4.8
> Reporter: Stephen Mallette
> Priority: Major
>
> This issue may be discussed on a separate ticket somewhere already because I
> feel like it has come up before, but I can't find it immediately. Some steps
> can base their arguments on the result of `Traversal` and some cannot. This
> leads to folks trying things like:
> {code}
> g.V().hasLabel('Person').sample(math('4/2'))
> {code}
> and getting an error. Obviously the above is bit of a contrived example but
> one could imagine modifying the sample size based on some data dynamically
> gathered in the traversal itself. We could proliferate {{Traversal}}
> overloads everywhere for all steps and make it a rule that they should work
> that way or perhaps there is a more elegant approach that hasn't been
> considered yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
