[jira] [Comment Edited] (TINKERPOP-1048) Vertex lookups by id are inconsistent
[
https://issues.apache.org/jira/browse/TINKERPOP-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369435#comment-16369435
]
Daniel Kuppitz edited comment on TINKERPOP-1048 at 2/19/18 7:27 PM:
We can make it so that {{within}} and {{without}} also use {{NumberHelper}},
but this wouldn't work without a performance penalty. However, I don't think
providers would be affected by this, as most of them should have their own way
for internal id lookups anyway.
Actually, I'm wondering what we see as the correct behavior.
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
gremlin>
{noformat}
This?
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
==>v[3]
==>v[2]
==>v[4]
==>v[5]
==>v[3]
==>v[3]
{noformat}
Or that?
Thoughts?
*UPDATE:*
The first snippet it obviously wrong, as the first {{hasId(within(1..6))}}
returns all vertices, while the second {{hasId(within(1..6))}} filters them
all. I think I think {{NumberHelper::equals}} will be the way to go.
was (Author: dkuppitz):
We can make it so that {{within}} and {{without}} also use {{NumberHelper}},
but this wouldn't work without a performance penalty. However, I don't think
providers would be affected by this, as most of them should have their own way
for internal id lookups anyway.
Actually, I'm wondering what we see as the correct behavior.
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
gremlin>
{noformat}
This?
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
==>v[3]
==>v[2]
==>v[4]
==>v[5]
==>v[3]
==>v[3]
{noformat}
Or that?
Thoughts?
> Vertex lookups by id are inconsistent
> -
>
> Key: TINKERPOP-1048
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1048
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.1.1-incubating
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> {{graph.vertices(id)}}, {{g.V(id)}} and {{g.V().hasId(id)}} should all return
> the same result. However, currently only the latter respects the
> {{toString()}} representation of ids.
> {noformat}
> gremlin> g.addV().id()
> ==>12
> gremlin> graph.vertices("12")
> gremlin> g.V("12")
> gremlin> g.V().hasId("12")
> ==>v[12]
> {noformat}
> Inconsistent number comparison with Contains:
> {noformat}
> gremlin> conf = new BaseConfiguration()
> ==>org.apache.commons.configuration.BaseConfiguration@7048535f
> gremlin> conf.setProperty("gremlin.tinkergraph.vertexIdManager","LONG")
> ==>null
> gremlin> conf.setProperty("gremlin.tinkergraph.edgeIdManager","LONG")
> ==>null
> gremlin> graph = TinkerGraph.open(conf)
> ==>tinkergraph[vertices:0 edges:0]
> gremlin> graph.io(gryo()).readGraph('data/tinkerpop-modern.kryo')
> ==>null
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
> gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
> ==>v[3]
> ==>v[2]
> ==>v[4]
> ==>v[5]
> ==>v[3]
> ==>v[3]
> {noformat}
> `P.within` and `P.without` rely on `Collection.contains()` which ends up
> doing an Object type comparison during the equality check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-1048) Vertex lookups by id are inconsistent
[
https://issues.apache.org/jira/browse/TINKERPOP-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369435#comment-16369435
]
Daniel Kuppitz edited comment on TINKERPOP-1048 at 2/19/18 7:27 PM:
We can make it so that {{within}} and {{without}} also use {{NumberHelper}},
but this wouldn't work without a performance penalty. However, I don't think
providers would be affected by this, as most of them should have their own way
for internal id lookups anyway.
Actually, I'm wondering what we see as the correct behavior.
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
gremlin>
{noformat}
This?
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
==>v[3]
==>v[2]
==>v[4]
==>v[5]
==>v[3]
==>v[3]
{noformat}
Or that?
Thoughts?
*UPDATE:*
The first snippet is obviously wrong, as the first {{hasId(within(1..6))}}
returns all vertices, while the second {{hasId(within(1..6))}} filters them
all. I think I think {{NumberHelper::equals}} will be the way to go.
was (Author: dkuppitz):
We can make it so that {{within}} and {{without}} also use {{NumberHelper}},
but this wouldn't work without a performance penalty. However, I don't think
providers would be affected by this, as most of them should have their own way
for internal id lookups anyway.
Actually, I'm wondering what we see as the correct behavior.
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
gremlin>
{noformat}
This?
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
==>v[3]
==>v[2]
==>v[4]
==>v[5]
==>v[3]
==>v[3]
{noformat}
Or that?
Thoughts?
*UPDATE:*
The first snippet it obviously wrong, as the first {{hasId(within(1..6))}}
returns all vertices, while the second {{hasId(within(1..6))}} filters them
all. I think I think {{NumberHelper::equals}} will be the way to go.
> Vertex lookups by id are inconsistent
> -
>
> Key: TINKERPOP-1048
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1048
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.1.1-incubating
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> {{graph.vertices(id)}}, {{g.V(id)}} and {{g.V().hasId(id)}} should all return
> the same result. However, currently only the latter respects the
> {{toString()}} representation of ids.
> {noformat}
> gremlin> g.addV().id()
> ==>12
> gremlin> graph.vertices("12")
> gremlin> g.V("12")
> gremlin> g.V().hasId("12")
> ==>v[12]
> {noformat}
> Inconsistent number comparison with Contains:
> {noformat}
> gremlin> conf = new BaseConfiguration()
> ==>org.apache.commons.configuration.BaseConfiguration@7048535f
> gremlin> conf.setProperty("gremlin.tinkergraph.vertexIdManager","LONG")
> ==>null
> gremlin> conf.setProperty("gremlin.tinkergraph.edgeIdManager","LONG")
> ==>null
> gremlin> graph = TinkerGraph.open(conf)
> ==>tinkergraph[vertices:0 edges:0]
> gremlin> graph.io(gryo()).readGraph('data/tinkerpop-modern.kryo')
> ==>null
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
> gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
> ==>v[3]
> ==>v[2]
> ==>v[4]
> ==>v[5]
> ==>v[3]
> ==>v[3]
> {noformat}
> `P.within` and `P.without` rely on `Collection.contains()` which ends up
> doing an Object type comparison during the equality check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-1048) Vertex lookups by id are inconsistent
[
https://issues.apache.org/jira/browse/TINKERPOP-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369435#comment-16369435
]
Daniel Kuppitz edited comment on TINKERPOP-1048 at 2/19/18 7:24 PM:
We can make it so that {{within}} and {{without}} also use {{NumberHelper}},
but this wouldn't work without a performance penalty. However, I don't think
providers would be affected by this, as most of them should have their own way
for internal id lookups anyway.
Actually, I'm wondering what we see as the correct behavior.
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
gremlin>
{noformat}
This?
{noformat}
gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
==>v[3]
==>v[2]
==>v[4]
==>v[5]
==>v[3]
==>v[3]
{noformat}
Or that?
Thoughts?
was (Author: dkuppitz):
We can make it so that {{within}} and {{without}} also use {{NumberHelper}},
but this wouldn't work without a performance penalty. However, I don't think
providers would be affected by this, as most of them should have their own way
for internal id lookups anyway.
Thoughts?
> Vertex lookups by id are inconsistent
> -
>
> Key: TINKERPOP-1048
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1048
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.1.1-incubating
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> {{graph.vertices(id)}}, {{g.V(id)}} and {{g.V().hasId(id)}} should all return
> the same result. However, currently only the latter respects the
> {{toString()}} representation of ids.
> {noformat}
> gremlin> g.addV().id()
> ==>12
> gremlin> graph.vertices("12")
> gremlin> g.V("12")
> gremlin> g.V().hasId("12")
> ==>v[12]
> {noformat}
> Inconsistent number comparison with Contains:
> {noformat}
> gremlin> conf = new BaseConfiguration()
> ==>org.apache.commons.configuration.BaseConfiguration@7048535f
> gremlin> conf.setProperty("gremlin.tinkergraph.vertexIdManager","LONG")
> ==>null
> gremlin> conf.setProperty("gremlin.tinkergraph.edgeIdManager","LONG")
> ==>null
> gremlin> graph = TinkerGraph.open(conf)
> ==>tinkergraph[vertices:0 edges:0]
> gremlin> graph.io(gryo()).readGraph('data/tinkerpop-modern.kryo')
> ==>null
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().hasId(within(1..6)).out().hasId(within(1..6))
> gremlin> g.V().hasId(within(1..6)).out().hasId(between(0,7))
> ==>v[3]
> ==>v[2]
> ==>v[4]
> ==>v[5]
> ==>v[3]
> ==>v[3]
> {noformat}
> `P.within` and `P.without` rely on `Collection.contains()` which ends up
> doing an Object type comparison during the equality check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
