[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=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=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=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=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/traversal/P;)Lorg/apach
[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=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=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=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=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=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=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=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=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
Report
> Merging
[#2020](https://codecov.io/gh/apache/tinkerpop/pull/2020?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
(9dd83a1) into
[3.6-dev](https://codecov.io/gh/apache/tinkerpop/commit/3249e5856fee577cae9a2f69260cbc6c6c1ffd66?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_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=tree-more_medium=referral_source=github_content=comment_campaign=pr+comments_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_source=github_content=comment_campaign=pr+comments_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=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=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=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=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=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=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=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
Report
> Merging
[#2019](https://codecov.io/gh/apache/tinkerpop/pull/2019?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
(fbc381f) into
[3.5-dev](https://codecov.io/gh/apache/tinkerpop/commit/deba2153bf3dd5e174db8cbd176eaf37b660033e?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_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=tree-more_medium=referral_source=github_content=comment_campaign=pr+comments_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_source=github_content=comment_campaign=pr+comments_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=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=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=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=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=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=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=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] [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=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=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=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=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=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=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=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)
[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=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 <okramma...@gmail.com>
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 <okramma...@gmail.com> 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 <m...@gremlin.guru> 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 <pieter.mar...@gmail.com>
> 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 <pieter.mar...@gmail.com>
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
