[
https://issues.apache.org/jira/browse/TINKERPOP-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Häusler updated TINKERPOP-3184:
--------------------------------------
Description:
Hello,
I am once again dealing with paths. I noticed that it is currently possible to
do the following:
{code:java}
traversal().V()
// ... navigation...
.path()
.unfold()
{code}
... which is very neat. I was wondering if I can also get the path between a
label and the current vertex. Turns out, I can:
{code:java}
traversal().V()
// ... navigation ...
.as("from")
// ... navigation...
.flatMap ( t-> t.path().subPath("from", null).iterator())
{code}
That is very useful! But it's a shame that the functionality is locked behind a
lambda expression, which is not available in all scenarios. Moreover, gremlin
optimizes away the path information tracking if no "path()" step is used in the
query, so the lambda solution always requires some additional artificial steps
on top.
My proposal would be to add the following overload to the "path()" method:
{code:java}
public default GraphTraversal<S, Path> path(String fromLabel, String toLabel)
{code}
... which behaves exactly like the lambda above. Both "fromLabel" and "toLabel"
should accept NULL (same as "subPath(...)") which means start/end of the path
respectively. Therefore calling "path()" would be the same as "path(null,
null)".
was:
Hello,
I am once again dealing with paths. I noticed that it is currently possible to
do the following:
{code:java}
traversal().V()
// ... navigation...
.path()
.unfold()
{code}
... which is very neat. I was wondering if I can also get the path between a
label and the current vertex. Turns out, I can:
{code:java}
traversal().V()
// ... navigation ...
.as("from")
// ... navigation...
.flatMap {
it.path().subPath("from", null).iterator()
}
{code}
That is very useful! But it's a shame that the functionality is locked behind a
lambda expression, which is not available in all scenarios. Moreover, gremlin
optimizes away the path information tracking if no "path()" step is used in the
query, so the lambda solution always requires some additional artificial steps
on top.
My proposal would be to add the following overload to the "path()" method:
{code:java}
public default GraphTraversal<S, Path> path(String fromLabel, String toLabel)
{code}
... which behaves exactly like the lambda above. Both "fromLabel" and "toLabel"
should accept NULL (same as "subPath(...)") which means start/end of the path
respectively. Therefore calling "path()" would be the same as "path(null,
null)".
> Please allow the path() step to take an optional from and to label
> ------------------------------------------------------------------
>
> Key: TINKERPOP-3184
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3184
> Project: TinkerPop
> Issue Type: Wish
> Affects Versions: 3.7.4
> Reporter: Martin Häusler
> Priority: Major
>
> Hello,
> I am once again dealing with paths. I noticed that it is currently possible
> to do the following:
> {code:java}
> traversal().V()
> // ... navigation...
> .path()
> .unfold()
> {code}
> ... which is very neat. I was wondering if I can also get the path between a
> label and the current vertex. Turns out, I can:
> {code:java}
> traversal().V()
> // ... navigation ...
> .as("from")
> // ... navigation...
> .flatMap ( t-> t.path().subPath("from", null).iterator())
> {code}
> That is very useful! But it's a shame that the functionality is locked behind
> a lambda expression, which is not available in all scenarios. Moreover,
> gremlin optimizes away the path information tracking if no "path()" step is
> used in the query, so the lambda solution always requires some additional
> artificial steps on top.
> My proposal would be to add the following overload to the "path()" method:
> {code:java}
> public default GraphTraversal<S, Path> path(String fromLabel, String toLabel)
> {code}
> ... which behaves exactly like the lambda above. Both "fromLabel" and
> "toLabel" should accept NULL (same as "subPath(...)") which means start/end
> of the path respectively. Therefore calling "path()" would be the same as
> "path(null, null)".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
