You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Daniel Kuppitz (JIRA)" <ji...@apache.org> on 2018/02/20 18:24:00 UTC

[jira] [Commented] (TINKERPOP-1463) Improve has(propertyKey, traversal)

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

Daniel Kuppitz commented on TINKERPOP-1463:
-------------------------------------------

18 months later I still don't like {{has(key, traversal)}}, it just doesn't make any sense to me. It would make more sense if the filter-traversal would at least start from the property, not from the value. Then we could use it to filter vertices based on meta-properties.

{noformat}
gremlin> g = TinkerFactory.createTheCrew().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:14], standard]
gremlin> g.V().has('location', has('startTime', lt(2000)))
...
gremlin> g.V().has('location', __.as('a','b').math('a-b').by('endTime).by('startTime').is(gte(10)))
{noformat}

Anyway, I guess at this point it's way too late to change the behavior (although I doubt that anybody is really using this has-overload).

Close as _Won't Fix_?

> Improve has(propertyKey, traversal)
> -----------------------------------
>
>                 Key: TINKERPOP-1463
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1463
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.2.5
>            Reporter: Daniel Kuppitz
>            Priority: Major
>
> 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
(v7.6.3#76005)