You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Kelvin R. Lawrence (Jira)" <ji...@apache.org> on 2020/09/03 16:39:00 UTC

[jira] [Commented] (TINKERPOP-2414) Dynamic options for all steps

    [ 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)