Daniel Kuppitz created TINKERPOP-1463:
-----------------------------------------
Summary: Improve has(propertyKey, traversal)
Key: TINKERPOP-1463
URL: https://issues.apache.org/jira/browse/TINKERPOP-1463
Project: TinkerPop
Issue Type: Improvement
Components: process
Reporter: Daniel Kuppitz
Two issues here:
{{.has(propertyKey, traversal)}} kinda doesn't work as expected:
{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.addV(label, "software", "lang", "python")
==>v[12]
gremlin> g.V().has("name","lop").values("lang").as("l").V().has("lang",
select("l"))
==>v[3]
==>v[5]
==>v[12]
gremlin> g.V().has("name","lop").values("lang").as("l").V().has("lang",
__.where(eq("l")))
==>v[3]
==>v[5]
{code}
>From a user perspective {{.has("lang", select("l"))}} is / would be
>self-explanatory, {{.has("lang", __.where(eq("l")))}} on the other hand is
>confusing and I don't see good use-cases for it, as you could also write:
{code}
g.V().has("name","lop").values("lang").as("l").V().where(values("lang").as("l"))
{code}
The second issue or follow-up issue is, that has-traversal should be folded
into the {{GraphStep}}, so that the mid-traversal {{V()}} is not a full graph
scan. Given the traversal:
{code}
g.V().has("name","lop").values("lang").as("l").V().has("lang", select("l"))
{code}
... we would know the value of {{"l"}} at runtime. Thus it's not much different
from
{code}
g.V().has("name","lop").values("lang").as("l").V().has("lang", "java")
{code}
The only difference is that the latter traversal knows that the {{lang}} value
is {{java}} at compile time and the former traversal only knows it at runtime.
In either case the value is known before it's needed for the mid-traversal
{{V().has(...)}} lookup part.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
