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

["Kelvin R. Lawrence (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190291#comment-17190291 ] 

Kelvin R. Lawrence edited comment on TINKERPOP-2414 at 9/3/20, 6:27 PM:
------------------------------------------------------------------------

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())}}

Another common example involves {{hasId. }}People expect this to work

{{g.inject(3L).as('x').V().hasId(select('x'))}}

Where you need to do something like

{{ g.inject(3L).as('x').V().where(id().as('x')) }}


was (Author: gfxman):
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)