[
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 predica
: 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 ha
/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: TI
", "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 c
., 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();
g
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(
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
> 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
>
[
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
://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.
://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.
://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 I
://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-traver
://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
>
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
: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 incor
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-traver
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-traver
} 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
* *
```
> Ha
: 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
://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: TI
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
>
: 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
: 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
[
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 l
[
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 gi
[
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
[
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
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
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
>
> Improve behavior of hasId(null)
> ---
>
> Key: TINKERPOP-2645
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2645
> Project: TinkerPop
> Issue Type: Improvement
> Componen
:
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
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
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: TI
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 pas
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)
gr
[
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
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
> hasId() fails for empty collections
> ---
>
> Key: TINKERPOP-1802
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1802
> Project: TinkerPop
> Issue Type: Bug
> Components: proce
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
>
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/744
---
:
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
>
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/744
VOTE: +1
---
(`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
>
().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
>
. 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 li
:
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
>
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/744
VOTE +1
---
] Finished at: 2017-11-06T21:46:16-07:00
[INFO] Final Memory: 162M/1713M
[INFO]
```
> hasId() fails for empty collections
> ---
>
> Key: TINKERPOP-1802
>
:
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
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
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: TI
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
.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]
> ==&g
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]
gre
s =
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() {
fin
56 matches
Mail list logo
