[
https://issues.apache.org/jira/browse/TINKERPOP3-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031191#comment-15031191
]
Ted Wilmes commented on TINKERPOP3-968:
---------------------------------------
I was thinking about how this could be used within a match and came up with the
idea of nesting a traversal within an "optional" step.
{code}
g.V().hasLabel('customer').match(
__.as('cust').out('livesInCountry').as('country'),
__.as('cust').optional(out('livesInRegion')).as('region')
).select('cust', 'country', 'region')
{code}
In this case, if a customer did not have a region specified, you'd still
retrieve a result containing their customer & country.
{code}
==>[cust:v[96], country:v[136]]
{code}
I think you could simulate this to a certain extent with the or step, but it
would require some post match filtering to clean the results up.
[~pietermartin] given your example query:
{code}
g.V().hasLabel('A').out(true).out(true).toList();
{code}
perhaps that could turn into something like this which would support an
arbitrarily deep tree?
{code}
g.V().hasLabel('A').optional(
repeat(out())
).toList();
{code}
> Add first class support for an optional traversal
> -------------------------------------------------
>
> Key: TINKERPOP3-968
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-968
> Project: TinkerPop 3
> 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)
