[jira] [Commented] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876107#comment-17876107 ] Christopher Smith commented on TINKERPOP-3015: -- Commenting because I'm still running into this problem in new code with 3.7.2; I get the following compilation error (which correctly implements the generic semantics): {code} [Static type checking] - Cannot call org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#hasId(org.apache.tinkerpop.gremlin.process.traversal.P) with arguments [org.apache.tinkerpop.gremlin.process.traversal.P] {code} > Use wildcard instead of Object for hasId predicates > --- > > Key: TINKERPOP-3015 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3015 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.5.7, 3.6.5 >Reporter: Christopher Smith >Priority: Minor > > From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a > {{P}}. Common predicates, such as {{within}}, propagate the generic > type from their own arguments, so that this produces a compile-time error: > {code} > Collection ids = ... > g.V().hasId(P.within(ids)) > {code} > I believe that without loss of safety, the signature in both locations could > be changed to {{P}}, making the typical case of "here's a collection of > IDs of known type" work smoothly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cole Greer updated TINKERPOP-3015: -- Component/s: process > Use wildcard instead of Object for hasId predicates > --- > > Key: TINKERPOP-3015 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3015 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.5.7, 3.6.5 >Reporter: Christopher Smith >Priority: Minor > > From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a > {{P}}. Common predicates, such as {{within}}, propagate the generic > type from their own arguments, so that this produces a compile-time error: > {code} > Collection ids = ... > g.V().hasId(P.within(ids)) > {code} > I believe that without loss of safety, the signature in both locations could > be changed to {{P}}, making the typical case of "here's a collection of > IDs of known type" work smoothly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798360#comment-17798360 ] Christopher Smith commented on TINKERPOP-3015: -- That's exactly what I meant: The _implementation_ has a (kinda hacky) check to see if it is, but the actual API specification says that that method, which has a binary name, does something else. Updating the signature from {{P}} to {{P}} would align the specification and the ABI correctly. > Use wildcard instead of Object for hasId predicates > --- > > Key: TINKERPOP-3015 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3015 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.5.7, 3.6.5 >Reporter: Christopher Smith >Priority: Minor > > From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a > {{P}}. Common predicates, such as {{within}}, propagate the generic > type from their own arguments, so that this produces a compile-time error: > {code} > Collection ids = ... > g.V().hasId(P.within(ids)) > {code} > I believe that without loss of safety, the signature in both locations could > be changed to {{P}}, making the typical case of "here's a collection of > IDs of known type" work smoothly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798353#comment-17798353 ] Valentyn Kahamlyk commented on TINKERPOP-3015: -- now it's equivalent https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L2382 > Use wildcard instead of Object for hasId predicates > --- > > Key: TINKERPOP-3015 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3015 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.5.7, 3.6.5 >Reporter: Christopher Smith >Priority: Minor > > From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a > {{P}}. Common predicates, such as {{within}}, propagate the generic > type from their own arguments, so that this produces a compile-time error: > {code} > Collection ids = ... > g.V().hasId(P.within(ids)) > {code} > I believe that without loss of safety, the signature in both locations could > be changed to {{P}}, making the typical case of "here's a collection of > IDs of known type" work smoothly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798300#comment-17798300 ] Christopher Smith commented on TINKERPOP-3015: -- There exists a compilation error with that exact code in 3.5, and I suspect it also exists in 3.6 and 3.7. Specifically, even if your code words by coincidence, I believe inspecting the generated bytecode (e.g., with {{javap -v}}) will show that the wrong overload is being selected. {code}Collection asString = List.of("a", "b"); @SuppressWarnings({ "unchecked", "rawtypes" }) Collection asObject = (Collection) asString; gts.V().hasId(P.within(asString)).iterate(); gts.V().hasId(P.within(asObject)).iterate(); {code} correctly produces the following bytecode snippet, where you can see that the invocation of {{hasId(P)}} is resolved to {{hasId(Object, Object...)}} {code} #60 = InterfaceMethodref #61.#63 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.hasId:(Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #61 = Class #62 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal #62 = Utf8 org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal #63 = NameAndType#64:#65 // hasId:(Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #64 = Utf8 hasId #65 = Utf8 (Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #66 = InterfaceMethodref #61.#67 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.iterate:()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #67 = NameAndType#68:#69 // iterate:()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #68 = Utf8 iterate #69 = Utf8 ()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #70 = InterfaceMethodref #61.#71 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.hasId:(Lorg/apache/tinkerpop/gremlin/process/traversal/P;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; {code} The fact that this produces the desired results in the current implementation is an implementation detail and not guaranteed by the API semantics. > Use wildcard instead of Object for hasId predicates > --- > > Key: TINKERPOP-3015 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3015 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.5.7, 3.6.5 >Reporter: Christopher Smith > Priority: Minor > > From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a > {{P}}. Common predicates, such as {{within}}, propagate the generic > type from their own arguments, so that this produces a compile-time error: > {code} > Collection ids = ... > g.V().hasId(P.within(ids)) > {code} > I believe that without loss of safety, the signature in both locations could > be changed to {{P}}, making the typical case of "here's a collection of > IDs of known type" work smoothly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798300#comment-17798300 ] Christopher Smith edited comment on TINKERPOP-3015 at 12/18/23 5:58 PM: There exists a compilation error with that exact code in 3.5, and I suspect it also exists in 3.6 and 3.7. The _compilation will not fail_, but it will produce incorrect output. Specifically, even if your code words by coincidence, I believe inspecting the generated bytecode (e.g., with {{javap -v}}) will show that the wrong overload is being selected. {code}Collection asString = List.of("a", "b"); @SuppressWarnings({ "unchecked", "rawtypes" }) Collection asObject = (Collection) asString; gts.V().hasId(P.within(asString)).iterate(); gts.V().hasId(P.within(asObject)).iterate(); {code} correctly produces the following bytecode snippet, where you can see that the invocation of {{hasId(P)}} is resolved to {{hasId(Object, Object...)}} {code} #60 = InterfaceMethodref #61.#63 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.hasId:(Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #61 = Class #62 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal #62 = Utf8 org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal #63 = NameAndType#64:#65 // hasId:(Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #64 = Utf8 hasId #65 = Utf8 (Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #66 = InterfaceMethodref #61.#67 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.iterate:()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #67 = NameAndType#68:#69 // iterate:()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #68 = Utf8 iterate #69 = Utf8 ()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #70 = InterfaceMethodref #61.#71 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.hasId:(Lorg/apache/tinkerpop/gremlin/process/traversal/P;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; {code} The fact that this produces the desired results in the current implementation is an implementation detail and not guaranteed by the API semantics. was (Author: chrylis): There exists a compilation error with that exact code in 3.5, and I suspect it also exists in 3.6 and 3.7. Specifically, even if your code words by coincidence, I believe inspecting the generated bytecode (e.g., with {{javap -v}}) will show that the wrong overload is being selected. {code}Collection asString = List.of("a", "b"); @SuppressWarnings({ "unchecked", "rawtypes" }) Collection asObject = (Collection) asString; gts.V().hasId(P.within(asString)).iterate(); gts.V().hasId(P.within(asObject)).iterate(); {code} correctly produces the following bytecode snippet, where you can see that the invocation of {{hasId(P)}} is resolved to {{hasId(Object, Object...)}} {code} #60 = InterfaceMethodref #61.#63 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.hasId:(Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #61 = Class #62 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal #62 = Utf8 org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal #63 = NameAndType#64:#65 // hasId:(Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #64 = Utf8 hasId #65 = Utf8 (Ljava/lang/Object;[Ljava/lang/Object;)Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #66 = InterfaceMethodref #61.#67 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.iterate:()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #67 = NameAndType#68:#69 // iterate:()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #68 = Utf8 iterate #69 = Utf8 ()Lorg/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal; #70 = InterfaceMethodref #61.#71 // org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.hasId:(Lorg/apache/tinkerpop/gremlin/process/traversa
[jira] [Commented] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786480#comment-17786480 ] Valentyn Kahamlyk commented on TINKERPOP-3015: -- Could you share code example with compilation error? For me works without issues with latest 3.6.x and 3.7.x {code:java} Graph graph = TinkerFactory.createModern(); GraphTraversalSource g = graph.traversal(); Collection ids = Arrays.asList("1","2","3"); List vertices = g.V().hasId(P.within(ids)).toList(); System.out.println(vertices);{code} > Use wildcard instead of Object for hasId predicates > --- > > Key: TINKERPOP-3015 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3015 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.5.7, 3.6.5 >Reporter: Christopher Smith >Priority: Minor > > From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a > {{P}}. Common predicates, such as {{within}}, propagate the generic > type from their own arguments, so that this produces a compile-time error: > {code} > Collection ids = ... > g.V().hasId(P.within(ids)) > {code} > I believe that without loss of safety, the signature in both locations could > be changed to {{P}}, making the typical case of "here's a collection of > IDs of known type" work smoothly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
Christopher Smith created TINKERPOP-3015: Summary: Use wildcard instead of Object for hasId predicates Key: TINKERPOP-3015 URL: https://issues.apache.org/jira/browse/TINKERPOP-3015 Project: TinkerPop Issue Type: Improvement Affects Versions: 3.6.5, 3.5.7 Reporter: Christopher Smith >From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a >{{P}}. Common predicates, such as {{within}}, propagate the generic >type from their own arguments, so that this produces a compile-time error: {code} Collection ids = ... g.V().hasId(P.within(ids)) {code} I believe that without loss of safety, the signature in both locations could be changed to {{P}}, making the typical case of "here's a collection of IDs of known type" work smoothly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2863. --- Fix Version/s: 3.7.0 3.6.3 3.5.6 Resolution: Fixed > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Assignee: Yang Xia >Priority: Critical > Fix For: 3.7.0, 3.6.3, 3.5.6 > > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia reassigned TINKERPOP-2863: --- Assignee: Yang Xia > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Assignee: Yang Xia >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714782#comment-17714782 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy merged PR #2020: URL: https://github.com/apache/tinkerpop/pull/2020 > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714780#comment-17714780 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy merged PR #2019: URL: https://github.com/apache/tinkerpop/pull/2019 > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713299#comment-17713299 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy commented on PR #2019: URL: https://github.com/apache/tinkerpop/pull/2019#issuecomment-1512109947 > This needs feature tests to enforce the behavior. Added in https://github.com/apache/tinkerpop/pull/2019/commits/be12e6cfbd6d16501fb0d680786261a7caae35d9 > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712333#comment-17712333 ] ASF GitHub Bot commented on TINKERPOP-2863: --- spmallette commented on PR #2019: URL: https://github.com/apache/tinkerpop/pull/2019#issuecomment-1508329466 This needs feature tests to enforce the behavior. > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712154#comment-17712154 ] ASF GitHub Bot commented on TINKERPOP-2863: --- kenhuuu commented on PR #2019: URL: https://github.com/apache/tinkerpop/pull/2019#issuecomment-1507835985 VOTE +1 > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
HasId() behaviour with list inputs
Hi all, I was looking at the ticket, https://issues.apache.org/jira/browse/TINKERPOP-2863, which reported an inconsistency between start-step hasId() and mid-traversal hasId(). It looks like this is due to hasId() treating list types (i.e. a Collection) as a single object and uses P.eq instead of P.within for comparison. Arrays are, however, unrolled in HasId() to be used with P.within, and I think this should also be applied to Collections, so I've implemented the fix here: https://github.com/apache/tinkerpop/pull/2019. In TinkerGraph, start-step hasId() does not have this issue, because it is pushed down to the g.V() step, which gets a uniform collection of ids from the HasContainer and compares each id individually. However, I just want to note that there has been a side effect with the unrolling of ids in the start-step hasId(), which is not being able to filter on any list typed ids, since we unroll all lists. As this fix will align the mid-traversal hasId() behaviour to the TinkerGraph historical behaviour, how hasId() handles list typed ids will now be changed slightly for providers. While I believe unrolling of ids is expected, feel free to shout out any concerns with this approach. Best, Yang *--* *Yang Xia*
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711599#comment-17711599 ] ASF GitHub Bot commented on TINKERPOP-2863: --- codecov-commenter commented on PR #2020: URL: https://github.com/apache/tinkerpop/pull/2020#issuecomment-1506078740 ## [Codecov](https://codecov.io/gh/apache/tinkerpop/pull/2020?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report > Merging [#2020](https://codecov.io/gh/apache/tinkerpop/pull/2020?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (9dd83a1) into [3.6-dev](https://codecov.io/gh/apache/tinkerpop/commit/3249e5856fee577cae9a2f69260cbc6c6c1ffd66?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (3249e58) will **decrease** coverage by `4.91%`. > The diff coverage is `n/a`. > :exclamation: Current head 9dd83a1 differs from pull request most recent head bd8253e. Consider uploading reports for the commit bd8253e to get more accurate results ```diff @@ Coverage Diff @@ ## 3.6-dev#2020 +/- ## = - Coverage 69.41% 64.51% -4.91% = Files878 25 -853 Lines 42083 3793 -38290 Branches56400-5640 = - Hits 29212 2447 -26765 + Misses 10877 1179-9698 + Partials1994 167-1827 ``` [see 853 files with indirect coverage changes](https://codecov.io/gh/apache/tinkerpop/pull/2020/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) :mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711595#comment-17711595 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy commented on code in PR #2020: URL: https://github.com/apache/tinkerpop/pull/2020#discussion_r1164737333 ## gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java: ## @@ -2528,7 +2524,7 @@ public default GraphTraversal property(final VertexProperty.Cardinality ca * the {@link Graph} will be used. * * If a {@link Map} is supplied then each of the key/value pairs in the map will - * be added as property. This method is the long-hand version of looping through the + * be added as property. This method is the long-hand version of looping through the Review Comment: ```suggestion * be added as property. This method is the long-hand version of looping through the ``` > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711596#comment-17711596 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy commented on code in PR #2020: URL: https://github.com/apache/tinkerpop/pull/2020#discussion_r1164737644 ## gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java: ## @@ -2561,14 +2557,14 @@ public default GraphTraversal property(final Object key, final Object valu return this.property(null, key, value, keyValues); } } - + /** * When a {@link Map} is supplied then each of the key/value pairs in the map will - * be added as property. This method is the long-hand version of looping through the + * be added as property. This method is the long-hand version of looping through the Review Comment: ```suggestion * be added as property. This method is the long-hand version of looping through the ``` > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711594#comment-17711594 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy commented on code in PR #2020: URL: https://github.com/apache/tinkerpop/pull/2020#discussion_r1164736990 ## gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java: ## @@ -2446,7 +2442,7 @@ public default GraphTraversal profile() { * and if the {@link Element} is a {@link VertexProperty}. This method is the long-hand version of * {@link #property(Object, Object, Object...)} with the difference that the {@link VertexProperty.Cardinality} * can be supplied. - * * + * * Review Comment: ```suggestion * * ``` > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711591#comment-17711591 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy opened a new pull request, #2020: URL: https://github.com/apache/tinkerpop/pull/2020 Same changes as #2019, but for 3.6-dev instead, as there was an added null check in hasId() for 3.6, which led to changes to the Gherkin test suites. It appears that the previous implementation of hasId() omitted adding `null` to the Bytecode step if `otherIds` were `null`, which unintentionally removed tailing nulls from traversals and in the test files. I'll squash all commits into one when this is ready to merge. > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711571#comment-17711571 ] ASF GitHub Bot commented on TINKERPOP-2863: --- vkagamlyk commented on PR #2019: URL: https://github.com/apache/tinkerpop/pull/2019#issuecomment-1505968768 LGTM, VOTE+1 > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711558#comment-17711558 ] ASF GitHub Bot commented on TINKERPOP-2863: --- codecov-commenter commented on PR #2019: URL: https://github.com/apache/tinkerpop/pull/2019#issuecomment-1505928566 ## [Codecov](https://codecov.io/gh/apache/tinkerpop/pull/2019?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report > Merging [#2019](https://codecov.io/gh/apache/tinkerpop/pull/2019?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (fbc381f) into [3.5-dev](https://codecov.io/gh/apache/tinkerpop/commit/deba2153bf3dd5e174db8cbd176eaf37b660033e?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (deba215) will **decrease** coverage by `5.18%`. > The diff coverage is `n/a`. ```diff @@ Coverage Diff @@ ## 3.5-dev#2019 +/- ## = - Coverage 69.33% 64.16% -5.18% = Files866 25 -841 Lines 41219 3750 -37469 Branches54320-5432 = - Hits 28581 2406 -26175 + Misses 10722 1166-9556 + Partials1916 178-1738 ``` [see 841 files with indirect coverage changes](https://codecov.io/gh/apache/tinkerpop/pull/2019/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) :mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711529#comment-17711529 ] ASF GitHub Bot commented on TINKERPOP-2863: --- vkagamlyk commented on code in PR #2019: URL: https://github.com/apache/tinkerpop/pull/2019#discussion_r1164551918 ## gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java: ## @@ -1608,35 +1608,31 @@ public default GraphTraversal hasId(final Object id, final Object... other return this.hasId((P) id); } else { -Object[] ids; +this.asAdmin().getBytecode().addStep(Symbols.hasId, id, otherIds); + +//using ArrayList given P.within() turns all arguments into lists +final List ids = new ArrayList<>(); if (id instanceof Object[]) { -ids = (Object[]) id; -} else { -ids = new Object[] {id}; -} -int size = ids.length; -int capacity = size; +Collections.addAll(ids, (Object[]) id); +} else if (id instanceof Collection) { + // when hasId() is pushed down to g.V() step, it unwraps any lists in ids into their individual elements, +// here we will do that with lists as well to remain consistent (TINKERPOP-2863) +ids.addAll((Collection) id); +} else +ids.add(id); + +// flattening ids from other lists in varargs works cleaner with lists, as otherwise any list will need to +// be turned into array first for (final Object i : otherIds) { if (i.getClass().isArray()) { Review Comment: ```suggestion if (i instanceof Object[]) { ``` > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711526#comment-17711526 ] ASF GitHub Bot commented on TINKERPOP-2863: --- xiazcy opened a new pull request, #2019: URL: https://github.com/apache/tinkerpop/pull/2019 https://issues.apache.org/jira/browse/TINKERPOP-2863 Aligned mid-traversal hasId() processing of lists with TinkerGraphStep filtering, to use P.within to check within lists of ids instead of using P.eq to compare entire list. This preserves the effect where that one cannot query list typed ids (because we look within the list) that has been present historically with vertex/edge id filtering in g.V()/g.E(). > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2863: Priority: Critical (was: Major) > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Critical > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette updated TINKERPOP-2863: Component/s: process > HasId Step generates incorrect results when given a list of IDs mid-traversal > - > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.6.2 >Reporter: Taylor Riggan >Priority: Major > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taylor Riggan updated TINKERPOP-2863: - Description: In most situations, hasId() will accept a list of potential IDs to filter on and implicitly use within() filtering semantics to return the correct results. Examples: {code:java} g.V().hasId(['1','2']) {code} returns: {code:java} [v[1], v[2]]{code} or {code:java} g.E().hasId(['5140','5261']){code} returns: {code:java} [e[5140][1-route->51], e[5261][1-route->398]]{code} However, when using the same form of semantics mid-traversal, both of these queries return empty results: {code:java} g.V().has('code','ATL').outE('route').hasId(['5140','5261']) g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) {code} When using profile() against both queries, the hasId() bytecode gets transformed into {code:java} HasStep([~id.eq([5140, 5261])]) {code} This equates to finding a vertex or edge with an ID that matches the entire list instead of the elements within the list. The preceding was tested against Gremlin Server 3.6.2 with the Airroutes dataset. was: In most situations, hasId() will accept a list of potential IDs to filter on and implicitly use within() filtering semantics to return the correct results. Examples: {code:java} g.V().hasId(['1','2']) {code} returns: {code:java} [v[1], v[2]]{code} or {code:java} g.E().hasId(['5140','5261']){code} returns: {code:java} [e[5140][1-route->51], e[5261][1-route->398]]{code} However, when using the same form of semantics mid-traversal, both of these queries return empty results: {code:java} g.V().has('code','ATL').outE('route').hasId(['5140','5261']) g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) {code} When using profile() against both queries, the hasId() bytecode gets transformed into {code:java} HasStep([~id.eq([5140, 5261])]) {code} This equates to finding a vertex with an ID that matches the entire list instead of the elements within the list. The preceding was tested against Gremlin Server 3.6.2 with the Airroutes dataset. > HasId Step generates incorrect results when given a list of IDs mid-traversal > ----- > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug >Affects Versions: 3.6.2 >Reporter: Taylor Riggan > Priority: Major > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex or edge with an ID that matches the entire > list instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[ https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taylor Riggan updated TINKERPOP-2863: - Description: In most situations, hasId() will accept a list of potential IDs to filter on and implicitly use within() filtering semantics to return the correct results. Examples: {code:java} g.V().hasId(['1','2']) {code} returns: {code:java} [v[1], v[2]]{code} or {code:java} g.E().hasId(['5140','5261']){code} returns: {code:java} [e[5140][1-route->51], e[5261][1-route->398]]{code} However, when using the same form of semantics mid-traversal, both of these queries return empty results: {code:java} g.V().has('code','ATL').outE('route').hasId(['5140','5261']) g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) {code} When using profile() against both queries, the hasId() bytecode gets transformed into {code:java} HasStep([~id.eq([5140, 5261])]) {code} This equates to finding a vertex with an ID that matches the entire list instead of the elements within the list. The preceding was tested against Gremlin Server 3.6.2 with the Airroutes dataset. was: In most situations, hasId() will accept a list of potential IDs to filter on and implicitly use within() filtering semantics to return the correct results. Examples: {code:java} g.V().hasId(['1','2']) {code} returns: {code:java} [v[1], v[2]]{code} or {code:java} g.E().hasId(['5140','5261']){code} returns: {code:java} [e[5140][1-route->51], e[5261][1-route->398]]{code} However, when using the same form of semantics mid-traversal, both of these queries return empty results: {code:java} g.V().has('code','ATL').outE('route').hasId(['5140','5261']) g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) {code} When using profile() against both queries, the hasId() bytecode gets transformed into {code:java} HasStep([~id.eq([5140, 5261])]) {code} This equates to finding a vertex with an ID that matches the entire list instead of the elements within the list. The preceding was tested against Gremlin Server 3.6.2 with the Airroutes dataset. > HasId Step generates incorrect results when given a list of IDs mid-traversal > ----- > > Key: TINKERPOP-2863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 > Project: TinkerPop > Issue Type: Bug >Affects Versions: 3.6.2 >Reporter: Taylor Riggan > Priority: Major > > In most situations, hasId() will accept a list of potential IDs to filter on > and implicitly use within() filtering semantics to return the correct > results. Examples: > {code:java} > g.V().hasId(['1','2']) > {code} > returns: > {code:java} > [v[1], v[2]]{code} > or > {code:java} > g.E().hasId(['5140','5261']){code} > returns: > {code:java} > [e[5140][1-route->51], e[5261][1-route->398]]{code} > However, when using the same form of semantics mid-traversal, both of these > queries return empty results: > {code:java} > g.V().has('code','ATL').outE('route').hasId(['5140','5261']) > g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) > {code} > When using profile() against both queries, the hasId() bytecode gets > transformed into > {code:java} > HasStep([~id.eq([5140, 5261])]) {code} > This equates to finding a vertex with an ID that matches the entire list > instead of the elements within the list. > The preceding was tested against Gremlin Server 3.6.2 with the Airroutes > dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
Taylor Riggan created TINKERPOP-2863: Summary: HasId Step generates incorrect results when given a list of IDs mid-traversal Key: TINKERPOP-2863 URL: https://issues.apache.org/jira/browse/TINKERPOP-2863 Project: TinkerPop Issue Type: Bug Affects Versions: 3.6.2 Reporter: Taylor Riggan In most situations, hasId() will accept a list of potential IDs to filter on and implicitly use within() filtering semantics to return the correct results. Examples: {code:java} g.V().hasId(['1','2']) {code} returns: {code:java} [v[1], v[2]]{code} or {code:java} g.E().hasId(['5140','5261']){code} returns: {code:java} [e[5140][1-route->51], e[5261][1-route->398]]{code} However, when using the same form of semantics mid-traversal, both of these queries return empty results: {code:java} g.V().has('code','ATL').outE('route').hasId(['5140','5261']) g.V().has('code','ATL').outE('route').inV().hasId(['2','3']) {code} When using profile() against both queries, the hasId() bytecode gets transformed into {code:java} HasStep([~id.eq([5140, 5261])]) {code} This equates to finding a vertex with an ID that matches the entire list instead of the elements within the list. The preceding was tested against Gremlin Server 3.6.2 with the Airroutes dataset. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2645) Improve behavior of hasId(null)
[ https://issues.apache.org/jira/browse/TINKERPOP-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459251#comment-17459251 ] ASF GitHub Bot commented on TINKERPOP-2645: --- spmallette merged pull request #1511: URL: https://github.com/apache/tinkerpop/pull/1511 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve behavior of hasId(null) > --- > > Key: TINKERPOP-2645 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2645 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.4.12 >Reporter: Stephen Mallette >Priority: Minor > > Instead of an error it should filter since no id can be null which would make > the behavior consistent with {{V(null)}} after TINKERPOP-2613. There are some > issues with old semantics of id lookups that are String related though along > with some other complexities around collections supplied to {{P.within}} that > make this a bit harder than it should be. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2645) Improve behavior of hasId(null)
[ https://issues.apache.org/jira/browse/TINKERPOP-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette closed TINKERPOP-2645. --- Fix Version/s: 3.6.0 Assignee: Stephen Mallette Resolution: Done > Improve behavior of hasId(null) > --- > > Key: TINKERPOP-2645 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2645 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.4.12 >Reporter: Stephen Mallette >Assignee: Stephen Mallette >Priority: Minor > Fix For: 3.6.0 > > > Instead of an error it should filter since no id can be null which would make > the behavior consistent with {{V(null)}} after TINKERPOP-2613. There are some > issues with old semantics of id lookups that are String related though along > with some other complexities around collections supplied to {{P.within}} that > make this a bit harder than it should be. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2645) Improve behavior of hasId(null)
[ https://issues.apache.org/jira/browse/TINKERPOP-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454798#comment-17454798 ] ASF GitHub Bot commented on TINKERPOP-2645: --- spmallette opened a new pull request #1511: URL: https://github.com/apache/tinkerpop/pull/1511 https://issues.apache.org/jira/browse/TINKERPOP-2645 No significant change here really - mostly more tests in this area and a restructuring of how collections passed to `hasId()` are handled. All tests pass with `docker/build.sh -t -n -i` VOTE +1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve behavior of hasId(null) > --- > > Key: TINKERPOP-2645 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2645 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.4.12 >Reporter: Stephen Mallette >Priority: Minor > > Instead of an error it should filter since no id can be null which would make > the behavior consistent with {{V(null)}} after TINKERPOP-2613. There are some > issues with old semantics of id lookups that are String related though along > with some other complexities around collections supplied to {{P.within}} that > make this a bit harder than it should be. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (TINKERPOP-2645) Improve behavior of hasId(null)
Stephen Mallette created TINKERPOP-2645: --- Summary: Improve behavior of hasId(null) Key: TINKERPOP-2645 URL: https://issues.apache.org/jira/browse/TINKERPOP-2645 Project: TinkerPop Issue Type: Improvement Components: process Affects Versions: 3.4.12 Reporter: Stephen Mallette Instead of an error it should filter since no id can be null which would make the behavior consistent with {{V(null)}} after TINKERPOP-2613. There are some issues with old semantics of id lookups that are String related though along with some other complexities around collections supplied to {{P.within}} that make this a bit harder than it should be. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[ https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Hupman closed TINKERPOP-2209. --- Resolution: Won't Fix Actually ended up being a duplicate of issue 1048 after further analysis. Opened up an [issue in JanusGraph|[https://github.com/JanusGraph/janusgraph/issues/1554]] to resolve this. > hasId is not converting properly when multiple values are passed > > > Key: TINKERPOP-2209 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2209 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.3 > Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook. >Reporter: Chris Hupman >Priority: Minor > > While [trying to answer a question on Stack Overflow > |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]] > I found that hasId is performing `~id.eq` against arrays instead of > `~id.within` For a workaround the user reporting the issue found that quoting > the values or converting them to longs worked. > > ``` > {{ids = [8440,12536]}} > {{paths = > g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}} > {{paths = > g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}} > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[ https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834206#comment-16834206 ] Chris Hupman commented on TINKERPOP-2209: - Thanks for the additional background info. I'll close this out and look into how much effort it would be to fix on the JanusGraph side. > hasId is not converting properly when multiple values are passed > > > Key: TINKERPOP-2209 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2209 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.3 > Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook. >Reporter: Chris Hupman >Priority: Minor > > While [trying to answer a question on Stack Overflow > |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]] > I found that hasId is performing `~id.eq` against arrays instead of > `~id.within` For a workaround the user reporting the issue found that quoting > the values or converting them to longs worked. > > ``` > {{ids = [8440,12536]}} > {{paths = > g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}} > {{paths = > g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}} > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[ https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834193#comment-16834193 ] Daniel Kuppitz commented on TINKERPOP-2209: --- This is a known issue: https://issues.apache.org/jira/browse/TINKERPOP-1048 Unfortunately, I don't think we can change that. TinkerPop itself ignores numeric data types (meaning, an Integer 1 is considered equal to a Long 1). But when it comes to the graph step, it's really up to the provider, e.g. how he decides to translate the provided input variables to a backend query. I'm not entirely sure about it, but my guess is, that there are 2 different code paths in {{JanusGraphStep}} / {{JanusGraphStepStrategy}} - one of them converts the Integers, the other doesn't. > hasId is not converting properly when multiple values are passed > > > Key: TINKERPOP-2209 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2209 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.3 > Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook. >Reporter: Chris Hupman >Priority: Minor > > While [trying to answer a question on Stack Overflow > |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]] > I found that hasId is performing `~id.eq` against arrays instead of > `~id.within` For a workaround the user reporting the issue found that quoting > the values or converting them to longs worked. > > ``` > {{ids = [8440,12536]}} > {{paths = > g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}} > {{paths = > g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}} > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[ https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834145#comment-16834145 ] Chris Hupman commented on TINKERPOP-2209: - Thanks for the info Daniel. I have a better understanding of what was causing the issue now after some additional testing. I'm still seeing an issue, but hopefully I can frame it better now. Even if you surround ids with a within() step or append toArray() you won't get any actual results. {code:java} gremlin> ids = [4112,4128,4136,8232,12328,16424,20520,4296,4328,4344,8440,12536] ==>4112 ==>4128 ==>4136 ==>8232 ==>12328 ==>16424 ==>20520 ==>4296 ==>4328 ==>4344 ==>8440 ==>12536 gremlin> paths = g.V(ids).until(hasId(within(ids))).repeat(bothE().otherV().simplePath()).path().limit(5) gremlin> {code} but I did get results when I generated the id like this {code:java} gremlin> ids = g.V().id().toList() 12:47:28 WARN org.janusgraph.graphdb.transaction.StandardJanusGraphTx - Query requires iterating over all vertices [()]. For better performance, use indexes ==>4112 ==>4128 ==>4136 ==>8232 ==>12328 ==>16424 ==>20520 ==>4296 ==>4328 ==>4344 ==>8440 ==>12536 gremlin> g.V(ids).until(hasId(within(ids))).repeat(bothE().otherV().simplePath()).path().limit(5) ==>[v[4112]] ==>[v[4128]] ==>[v[4136]] ==>[v[8232]] ==>[v[12328]] {code} It works because the array is being populated with Longs instead of ints. The real issue the user was having is that hasId GraphStep isn't converting the values to Longs, but g.V(ids) will convert them, creating confusion. I've only really looked through the JanusGraph/Titan source, but my understanding is that vertex ids are always longs. It think the bug should be framed as hasId should try to convert ints to Longs. Strings are already properly converted. > hasId is not converting properly when multiple values are passed > > > Key: TINKERPOP-2209 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2209 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.3 > Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook. >Reporter: Chris Hupman >Priority: Minor > > While [trying to answer a question on Stack Overflow > |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]] > I found that hasId is performing `~id.eq` against arrays instead of > `~id.within` For a workaround the user reporting the issue found that quoting > the values or converting them to longs worked. > > ``` > {{ids = [8440,12536]}} > {{paths = > g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}} > {{paths = > g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}} > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[ https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834103#comment-16834103 ] Daniel Kuppitz commented on TINKERPOP-2209: --- This is the expected behavior. {{hasId}} accepts varargs; a collection is a single argument, thus it will be translated into {{eq()}}. However, if you pass an array, it will be translated into {{within}}. {code:java} gremlin> ids = [8440,12536] ==>8440 ==>12536 gremlin> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100] ==>[GraphStep(vertex,[8440, 12536]), RepeatStep(until([HasStep([~id.eq([8440, 12536])])]),[VertexStep(O gremlin> ids = [8440,12536].toArray() ==>8440 ==>12536 gremlin> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100] ==>[GraphStep(vertex,[8440, 12536]), RepeatStep(until([HasStep([~id.within([8440, 12536])])]),[VertexSt {code} {{g.V(ids)}} returns all vertices, because {{GraphStep}} is the only step that unfolds collections internally. {{g.V().hasId(ids)}} returns all vertices, because in this case, {{hasId}} gets folded into {{GraphStep}}. Theoretically, we could remove the automatic unfolding in {{GraphStep}}, but practically, this would be a major breaking change. Likewise, we can't do the automatic unfolding for every other step, as you wouldn't be able to actually test for equal collections anymore. > hasId is not converting properly when multiple values are passed > > > Key: TINKERPOP-2209 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2209 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.3 > Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook. >Reporter: Chris Hupman >Priority: Minor > > While [trying to answer a question on Stack Overflow > |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]] > I found that hasId is performing `~id.eq` against arrays instead of > `~id.within` For a workaround the user reporting the issue found that quoting > the values or converting them to longs worked. > > ``` > {{ids = [8440,12536]}} > {{paths = > g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}} > {{paths = > g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}} > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
[ https://issues.apache.org/jira/browse/TINKERPOP-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834084#comment-16834084 ] stephen mallette commented on TINKERPOP-2209: - i guess it gets folding differently into `GraphStep`: {code} gremlin> g.V().until(hasId(ids)).repeat(out().simplePath()).profile() ==>Traversal Metrics Step Count Traversers Time (ms)% Dur = TinkerGraphStep(vertex,[]) 6 6 0.32019.84 RepeatStep(until([HasStep([~id.eq([1, 2])]), Pr... 1.29680.16 HasStep([~id.eq([1, 2])]) 0.143 VertexStep(OUT,vertex) 8 8 0.247 PathFilterStep(simple) 8 8 0.219 RepeatEndStep 0.195 >TOTAL - - 1.617- gremlin> g.V().hasId(ids).profile() ==>Traversal Metrics Step Count Traversers Time (ms)% Dur = TinkerGraphStep(vertex,[1, 2]) 2 2 0.098 100.00 >TOTAL - - 0.098 - {code} > hasId is not converting properly when multiple values are passed > > > Key: TINKERPOP-2209 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2209 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.3 > Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook. >Reporter: Chris Hupman >Priority: Minor > > While [trying to answer a question on Stack Overflow > |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]] > I found that hasId is performing `~id.eq` against arrays instead of > `~id.within` For a workaround the user reporting the issue found that quoting > the values or converting them to longs worked. > > ``` > {{ids = [8440,12536]}} > {{paths = > g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}} > {{paths = > g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}} > {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}} > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed
Chris Hupman created TINKERPOP-2209: --- Summary: hasId is not converting properly when multiple values are passed Key: TINKERPOP-2209 URL: https://issues.apache.org/jira/browse/TINKERPOP-2209 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.3.3 Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook. Reporter: Chris Hupman While [trying to answer a question on Stack Overflow |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]] I found that hasId is performing `~id.eq` against arrays instead of `~id.within` For a workaround the user reporting the issue found that quoting the values or converting them to longs worked. ``` {{ids = [8440,12536]}} {{paths = g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}} {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}} {{paths = g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}} {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}} ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko A. Rodriguez closed TINKERPOP-1802. - Resolution: Fixed Fix Version/s: 3.3.1 3.2.7 > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > Fix For: 3.2.7, 3.3.1 > > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242684#comment-16242684 ] ASF GitHub Bot commented on TINKERPOP-1802: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/744 > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #744: TINKERPOP-1802: hasId() fails for empty collect...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/744 ---
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242649#comment-16242649 ] ASF GitHub Bot commented on TINKERPOP-1802: --- Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/744 VOTE: +1 > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #744: TINKERPOP-1802: hasId() fails for empty collections
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/744 VOTE: +1 ---
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242286#comment-16242286 ] Bob Briody commented on TINKERPOP-1802: --- bq. This has been fixed by simply filtering out (`filter(true)` in essence) all vertices once a `hasId([]) My fault - I misread this comment, got confused by `filter(true)`. Sorry for the noise. > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242271#comment-16242271 ] Robert Dale commented on TINKERPOP-1802: It looks that way to me already... {noformat} g.V().hasId([]).count() == 0 g.V().hasId(within([])).count() == 0 g.V().hasId(without([])).count() == 6 g.V().not(hasId([])).count() == 6 {noformat} > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242258#comment-16242258 ] Bob Briody commented on TINKERPOP-1802: --- The implementation of this seems backwards to me. The `hasId` Step semantics are "If an Element Traverser has an ID matching one of the items in this list, then emit it, else not.". So when the list is empty, no Element Traversers should be emitted, because no Element Traversers have an ID matching an item in the list. That may seem like a silly thing to do - why specify an empty list that's just going to filter out all vertices? Well, if a developer were hard coding an empty array then that would be true, but I doubt that is how this will ever come up in practice. In practice, I think it will be much more likely for an empty array to arrive in a `hasId` step programatically. For example, "Get a list of the IDs of Bob's friends. Now use that list in a hasId step in a Traversal. ...But suppose Bob doesn't have any friends - that list will be empty." This creates situations where things get really ugly, such as this: {code:java} def t = g.V(targetId); t = existingEdgeIds.length == 0 ? t : t.has(id, without(existingEdgeIds)); {code} ...because in order to achieve the natural semantics, one has to modify their Traversal depending on dynamic ID lists. So, I can see why it might seem obvious to assume that an empty list should imply that no filtering occurs, and I realize that there are consistency concerns wrt g.V()/g.E(), but I still think that the pragmatic usage of this step justifies the behavior I described. > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz > Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242228#comment-16242228 ] ASF GitHub Bot commented on TINKERPOP-1802: --- Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/744 VOTE +1 > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #744: TINKERPOP-1802: hasId() fails for empty collections
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/744 VOTE +1 ---
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241996#comment-16241996 ] ASF GitHub Bot commented on TINKERPOP-1802: --- Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/744 ``` [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 04:37 h [INFO] Finished at: 2017-11-06T21:46:16-07:00 [INFO] Final Memory: 162M/1713M [INFO] ``` > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #744: TINKERPOP-1802: hasId() fails for empty collections
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/744 ``` [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 04:37 h [INFO] Finished at: 2017-11-06T21:46:16-07:00 [INFO] Final Memory: 162M/1713M [INFO] ``` ---
[jira] [Commented] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241159#comment-16241159 ] ASF GitHub Bot commented on TINKERPOP-1802: --- GitHub user okram opened a pull request: https://github.com/apache/tinkerpop/pull/744 TINKERPOP-1802: hasId() fails for empty collections https://issues.apache.org/jira/browse/TINKERPOP-1802 If `hasId([])` is specified, then an `ArrayOutOfBoundsException` occurs. This has been fixed by simply filtering out (`filter(true)` in essence) all vertices once a `hasId([])` is reached. cc/ @rjbriody VOTE +1. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1802 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/744.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #744 commit 74ca03dea1a7db7b2af39f46020cf8a75a2ea5c4 Author: Marko A. Rodriguez Date: 2017-11-06T21:36:22Z fixed a hasId([]) ArrayOutOfBoundsException bug that occurs in the rare situation where a user provides an empty collection of ids. Test cases developed by @dkuppitz. > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #744: TINKERPOP-1802: hasId() fails for empty collect...
GitHub user okram opened a pull request: https://github.com/apache/tinkerpop/pull/744 TINKERPOP-1802: hasId() fails for empty collections https://issues.apache.org/jira/browse/TINKERPOP-1802 If `hasId([])` is specified, then an `ArrayOutOfBoundsException` occurs. This has been fixed by simply filtering out (`filter(true)` in essence) all vertices once a `hasId([])` is reached. cc/ @rjbriody VOTE +1. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1802 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/744.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #744 commit 74ca03dea1a7db7b2af39f46020cf8a75a2ea5c4 Author: Marko A. Rodriguez Date: 2017-11-06T21:36:22Z fixed a hasId([]) ArrayOutOfBoundsException bug that occurs in the rare situation where a user provides an empty collection of ids. Test cases developed by @dkuppitz. ---
[jira] [Assigned] (TINKERPOP-1802) hasId() fails for empty collections
[ https://issues.apache.org/jira/browse/TINKERPOP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz reassigned TINKERPOP-1802: - Assignee: Marko A. Rodriguez (was: Daniel Kuppitz) [~okram] Not sure if you got my mail, but I pushed my dev branch for this issue. Everything's working on the TinkerGraph side, but Neo4j is broken and I still can't get my debugger working with Neo4j. > hasId() fails for empty collections > --- > > Key: TINKERPOP-1802 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Daniel Kuppitz >Assignee: Marko A. Rodriguez >Priority: Major > > {noformat} > gremlin> g.V().hasId(within([])) > 0 > Type ':help' or ':h' for help. > Display stack trace? [yN] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1802) hasId() fails for empty collections
Daniel Kuppitz created TINKERPOP-1802: - Summary: hasId() fails for empty collections Key: TINKERPOP-1802 URL: https://issues.apache.org/jira/browse/TINKERPOP-1802 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.2.6, 3.3.0 Reporter: Daniel Kuppitz Assignee: Daniel Kuppitz {noformat} gremlin> g.V().hasId(within([])) 0 Type ':help' or ':h' for help. Display stack trace? [yN] {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: hasId
I created the ticket: https://issues.apache.org/jira/browse/TINKERPOP-1681 On Sun, May 28, 2017 at 11:12 AM, Daniel Kuppitz wrote: > Hi Pieter, > > that's a nasty bug. I just verified that it's also a bug in master/: > > gremlin> graph = TinkerGraph.open() > ==>tinkergraph[vertices:0 edges:0] > gremlin> a = graph.addVertex(label, "A") > ==>v[0] > gremlin> b = graph.addVertex(label, "B") > ==>v[1] > gremlin> graph.traversal().V().hasId(a.id()).hasId(b.id()) > ==>v[0] > ==>v[1] > gremlin> graph.traversal().V().hasId(a.id()).hasId(b.id()).explain() > ==>Traversal Explanation > > == > Original Traversal [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > > ConnectiveStrategy [D] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > MatchPredicateStrategy [O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > FilterRankingStrategy[O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > InlineFilterStrategy [O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > RepeatUnrollStrategy [O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > CountStrategy[O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > PathRetractionStrategy [O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > LazyBarrierStrategy [O] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > TinkerGraphCountStrategy [P] [GraphStep(vertex,[]), > HasStep([~id.eq(0), ~id.eq(1)])] > TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[0, 1])] > ProfileStrategy [F] [TinkerGraphStep(vertex,[0, 1])] > StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[0, 1])] > > Final Traversal[TinkerGraphStep(vertex,[0, 1])] > gremlin> Gremlin.version() > ==>3.3.0-SNAPSHOT > > Can you create a ticket? > > Cheers, > Daniel > > > On Sun, May 28, 2017 at 10:45 AM, pieter gmail > wrote: > >> Hi, >> >> The following code illustrates my concern/confusion. >> >> @Test >> public void testHasId() { >> final TinkerGraph graph = TinkerGraph.open(); >> Vertex a = graph.addVertex(T.label, "A"); >> Vertex b = graph.addVertex(T.label, "B"); >> >> List vertices = graph.traversal().V().hasId(a.id >> ()).hasId(b.id()).toList(); >> Assert.assertTrue(vertices.isEmpty()); >> } >> >> The test fails as the both vertices are returned. >> Is this expected, I expected 'and' not 'or' behavior. >> >> Similar to, >> >> @Test >> public void testHasLabel() { >> final TinkerGraph graph = TinkerGraph.open(); >> Vertex a = graph.addVertex(T.label, "A"); >> Vertex b = graph.addVertex(T.label, "B"); >> >> List vertices = graph.traversal().V().hasLabel >> ("A").hasLabel("B").toList(); >> Assert.assertTrue(vertices.isEmpty()); >> } >> >> This one passes. >> >> I checked the docs, >> >> |hasLabel(labels...)|: Remove the traverser if its element does not have >> any of the labels. >> |hasId(ids...)|: Remove the traverser if its element does not have any of >> the ids. >> >> Seems they should behave the same? >> >> I am working on version 3.2.4 >> >> Thanks >> Pieter >> >> >
Re: hasId
Hi Pieter, that's a nasty bug. I just verified that it's also a bug in master/: gremlin> graph = TinkerGraph.open() ==>tinkergraph[vertices:0 edges:0] gremlin> a = graph.addVertex(label, "A") ==>v[0] gremlin> b = graph.addVertex(label, "B") ==>v[1] gremlin> graph.traversal().V().hasId(a.id()).hasId(b.id()) ==>v[0] ==>v[1] gremlin> graph.traversal().V().hasId(a.id()).hasId(b.id()).explain() ==>Traversal Explanation == Original Traversal [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] ConnectiveStrategy [D] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] MatchPredicateStrategy [O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] FilterRankingStrategy[O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] InlineFilterStrategy [O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] RepeatUnrollStrategy [O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] CountStrategy[O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] PathRetractionStrategy [O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] LazyBarrierStrategy [O] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] TinkerGraphCountStrategy [P] [GraphStep(vertex,[]), HasStep([~id.eq(0), ~id.eq(1)])] TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[0, 1])] ProfileStrategy [F] [TinkerGraphStep(vertex,[0, 1])] StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[0, 1])] Final Traversal[TinkerGraphStep(vertex,[0, 1])] gremlin> Gremlin.version() ==>3.3.0-SNAPSHOT Can you create a ticket? Cheers, Daniel On Sun, May 28, 2017 at 10:45 AM, pieter gmail wrote: > Hi, > > The following code illustrates my concern/confusion. > > @Test > public void testHasId() { > final TinkerGraph graph = TinkerGraph.open(); > Vertex a = graph.addVertex(T.label, "A"); > Vertex b = graph.addVertex(T.label, "B"); > > List vertices = graph.traversal().V().hasId(a.id()).hasId( > b.id()).toList(); > Assert.assertTrue(vertices.isEmpty()); > } > > The test fails as the both vertices are returned. > Is this expected, I expected 'and' not 'or' behavior. > > Similar to, > > @Test > public void testHasLabel() { > final TinkerGraph graph = TinkerGraph.open(); > Vertex a = graph.addVertex(T.label, "A"); > Vertex b = graph.addVertex(T.label, "B"); > > List vertices = graph.traversal().V().hasLabel > ("A").hasLabel("B").toList(); > Assert.assertTrue(vertices.isEmpty()); > } > > This one passes. > > I checked the docs, > > |hasLabel(labels...)|: Remove the traverser if its element does not have > any of the labels. > |hasId(ids...)|: Remove the traverser if its element does not have any of > the ids. > > Seems they should behave the same? > > I am working on version 3.2.4 > > Thanks > Pieter > >
RE: hasId
Hi, The following code illustrates my concern/confusion. @Test public void testHasId() { final TinkerGraph graph = TinkerGraph.open(); Vertex a = graph.addVertex(T.label, "A"); Vertex b = graph.addVertex(T.label, "B"); List vertices = graph.traversal().V().hasId(a.id()).hasId(b.id()).toList(); Assert.assertTrue(vertices.isEmpty()); } The test fails as the both vertices are returned. Is this expected, I expected 'and' not 'or' behavior. Similar to, @Test public void testHasLabel() { final TinkerGraph graph = TinkerGraph.open(); Vertex a = graph.addVertex(T.label, "A"); Vertex b = graph.addVertex(T.label, "B"); List vertices = graph.traversal().V().hasLabel("A").hasLabel("B").toList(); Assert.assertTrue(vertices.isEmpty()); } This one passes. I checked the docs, |hasLabel(labels...)|: Remove the traverser if its element does not have any of the labels. |hasId(ids...)|: Remove the traverser if its element does not have any of the ids. Seems they should behave the same? I am working on version 3.2.4 Thanks Pieter