thinkaurelius/titan — pull request #902 by dalaro (2014-12-23 20:42:06+00:00)
Title: Push down MultiKeySliceQuery cardinality check

This might fix #882. However, I'm not sure that the assumptions about MultiKeySliceQuery underlying this PR are correct.

The IndexSerializer.query precondition failing in #882 was introduced in 5a853d7a0866cc3eb0d65348303f7323386faa5d. This commit also introduced MultiKeySliceQuery (which has not been modified since) which is involved in the precondition.

The precondition fails when executing queries like this:

```
graph.query()
.has('label', ...)
.has(uniqueCompositeIndexedKey, Contain.IN, ...)
.vertices()
```

where multiple vertices have the specified label and satisfy the Contain.IN predicate. The composite index serving the query has Cardinality.SINGLE, but the MultiKSQ returns more than one vertex, failing the precondition.

I suspect, though I'm not certain, that this may reflect a shortcoming in the precondition. This commit moves the precondition down from IndexSerializer.query to MultiKeySliceQuery.execute (the latter is called from and only from the former). The new precondition assumes that each individual subquery inside the MultiKSQ will return at most one result when the index in question has Cardinality.SINGLE. The
difference is basically: before, we checked whether the aggregate result count of a MultiKSQ <= 1, now we check whether the result count of each individual subquery in the MultiKSQ <= 1 (when the index in
question is SINGLE).