[
https://issues.apache.org/jira/browse/TINKERPOP-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1484:
----------------------------------------
Priority: Minor (was: Major)
I think this all makes sense if you understand how the TinkerGraph indices
work.
> 1. The node is not found, although it's there.
> 2. The node is found if the property value is explicitly cast to long.
You made the value a Long so you must query it as a Long.
{code}
gremlin> g.V().has('prop', 1l)
==>v[0]
{code}
Values in indices are compared using {{.equals()}} so the type is taken into
account.
> 3. The node is found if the graph is queried on another indexed property
> first.
The TinkerGraph indices aren't super smart. I'm pretty sure that they grab the
first index in a set of {{has()}} steps and then uses that for the initial
index lookup then it in-memory filters the rest. So with TinkerGraph it is
always best to put highly selective properties first in a traversal. Note that
you get a result here because in-memory {{has}} is better at number comparison
and doesn't do {{.equals}} for those cases.
> 4. The node is found if the property value is wider than an int.
Based on my previous explanations, that's expected.
> v1. If the 'other' property is not indexed (line A), query (2) fails.
Again, my previous explanation explains this, but if you don't index "other"
then " TinkerGraph uses "prop" as the index and then you get nothing returned.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
Same thing - now you're all in-memory so {{has()}} in-memory filtering without
{{.equals()}} is in play.
I don't know how we would make all this work better offhand. Smarter indices?
We have similar annoyances with ids and {{.equals}}. I won't close this yet in
case anyone has ideas for what could be done to make this less confusing.
> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> ------------------------------------------------------------------------
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
> Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14
> Reporter: Florin Mihaila
> Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but
> not all) with properties of type long.
>
> The following code reproduces the bug:
>
> {code:title=bug.groovy}
> graph = TinkerGraph.open()
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class) // (B)
>
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>
> g = graph.traversal()
> {code}
>
> The verbatim console session:
>
> {noformat}
> $ bin/gremlin.sh bug.groovy
>
> \,,,/
> (o o)
> -----oOOo-(3)-oOOo-----
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1) // (1)
> gremlin> g.V().has('prop', (long)1) // (2)
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin>
>
> {noformat}
>
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed
> property first.
> 4. The node _is_ found if the property value is wider than an int.
>
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
