We are using JanusGraph (with Cassandra) as our backend database and facing some issues with the indexed property when using it in the has() clause.
The following query returns a null response:
g.V().has('fooName', 'fooValue').has('barName', 'barValue')
But, the following query returns the correct response:
g.V().has('barName', 'barValue').values('fooName')
==> fooValue
Both the properties are indexed (Composite). The data set is around 20k vertices with the value of 'fooName' property as 'fooValue', which is also confirmed with the following query which works:
g.V().has('fooName', 'fooValue').count()
==> 20000
This happens intermittently and not for all the vertices. Out of the 20k vertices, around 6k vertices show the above issue. The method of adding the property value is the same for all the vertices.
Is it the case that if we add a Composite Index for Vertices where the domain of values will be small and the range of sets of Vertices will be few with one set having a very large share of the universe that the resulting index queries will fail by falsely claiming that present Vertices that match the predicate are absent?
Rather than triggering a full scan, the traversals are reporting that the present Vertices are absent. If this is the case, at what threshold does the Composite Index begin to fail and where can this be tuned?
We are aware that there are recent changes to index caching and transactions. For the failing indexed query, we also observe that the "g.V().has( 'fooName', 'fooValue' ).count()" is limited to a query-limit value of 4000 (as shown in a .profile() report) until the transaction is committed. After the commit, the count() jumps back to the expected value. (20,000). Is this related?
