[ https://issues.apache.org/jira/browse/TINKERPOP-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085614#comment-16085614 ]
Robert Dale edited comment on TINKERPOP-1463 at 2/21/18 2:37 PM: ----------------------------------------------------------------- I would like to see this happen. It makes its use consistent with mutation steps and it's more intuitive. I think it would be a huge win for bytecode (and gremlin in general) where the traversal can be sent once with multiple data making it much faster than sending and/or iterating one traversal for each data point. Also for bytecode, this enables a form of batching transactions. (removed statement based on incorrect assumption of code) was (Author: rdale): I would like to see this happen. It makes its use consistent with mutation steps and it's more intuitive. I think it would be a huge win for bytecode (and gremlin in general) where the traversal can be sent once with multiple data making it much faster than sending and/or iterating one traversal for each data point. Also for bytecode, this enables a form of batching transactions. This: {noformat} g.inject(data).unfold().as('a').coalesce( V().has('myId',select('a').select('myId')), addV().property('myId',select('a').select('myId') ).property(...).iterate() {noformat} is much faster than {noformat} for (d in data) { g.inject(1).coalesce( V().has('myId',d.myId), addV().property('myId',d.myId) ).property(...).iterate() } {noformat} even when submitted as a gremlin script > 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)