[
https://issues.apache.org/jira/browse/TINKERPOP-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197771#comment-15197771
]
pieter martin commented on TINKERPOP-968:
-----------------------------------------
To describe it differently,
a1 ---ab--->b1
{code}
g.traversal().V(a1).out("ab").path()
{code}
returns
{code}
[v[0], v[2]]
{code}
{code}
g.traversal().V(a1).out("bb").path()
{code}
returns
{code}
nothing, not null but nothing
{code}
{code}
g.traversal().V(a1).optOut("ab").path()
{code}
returns
{code}
[v[0], v[2]]
{code}
{code}
g.traversal().V(a1).optOut("bb").path()
{code}
returns
{code}
[v[0]]
{code}
{code}
g.traversal().V(a1).optOut("aa", "bb").path()
{code}
returns both paths as both are valid traversals that returned something.
{code}
[v[0], v[2]]
[v[0]]
{code}
This can not be done with the choose step as it only checks till any label
returns something and then applies the regular {{out}} semantics with the
optional semantics being lost.
This makes me think that to support {{optional}} it needs to be a first first
class traversal, at the same level as {{out}} as oppose to being calculated by
higher level steps.
Thoughts?
> 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)
