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

pieter martin commented on TINKERPOP-968:
-----------------------------------------

I had a deja vu moment with the {{choose}} option.
This was discussed way back with 
[https://issues.apache.org/jira/browse/TINKERPOP-924].

So choose works but only if it is nested.

{{g.V().choose(out("knows"), out("knows"), identity()).choose(out("created"), 
out("created"), identity()).path()}}

This will also traverse the {{created}} edge on the {{identity()}} if there is 
no {{knows}} edge.
The {{optional}} semantics I envisage will not traverse {{created}} if 
{{knows}} can not be traversed.

In the previous example 
{code}
==>[v[4], v[5]]
==>[v[4], v[3]]
==>[v[6], v[3]]
{code}

are incorrect as {{v\[4\], v\[5\], v\[6\]}} {{knows}} nobody and {{created}} 
should not have been traversed.

{code}
gt = graph.traversal().V()
                .choose(
                        __.out("knows"),
                        __.out("knows").choose(
                                __.out("created"),
                                __.out("created"),
                                __.identity()
                        ),
                        __.identity()
                ).path();

[v[1], v[2]]
[v[1], v[4], v[5]]
[v[1], v[4], v[3]]
[v[2]]
[v[3]]
[v[4]]
[v[5]]
[v[6]]
{code}

is the expected results.


If we agree that the nested {{choose}} implements the expected semantics of 
{{optional}} then the question is whether {{optional}} does not deserve its own 
step.
The primary reason for this, is to ease the optimization of the {{optional}} 
step for implementers.

Optimizing nested {{choose}} steps is rather difficult.

> Add first class support for an optional traversal
> -------------------------------------------------
>
>                 Key: TINKERPOP-968
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-968
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.1.0-incubating
>            Reporter: pieter martin
>
> Both SparQL and Cypher use the "Optional" keyword to indicate an optional 
> traversal. SQL uses the "left join".
> Gremlin has no first class support for an optional traversal. It can be 
> achieved with the choose step but it is verbose, unintuitive and not what the 
> choose step is intended for.
> The benefits of optional traversals are many. In particular it makes it 
> trivial to load complete subgraphs/trees with one easy to read intuitive 
> gremlin statement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to