> Using the entryCount was our first option, but we decided to modify > costPerEntry instead. Basically these are the reasons:
What I meant was not the use of "entryCount" property but just that the sub index /nodeA/nodeB/includedC being a subset of /nodeA/nodeB/ it would have lower value for numDocs and hence any query having path restriction of /nodeA/nodeB/includedC would get to use that index (by virtue of numDocs being less than parent). So you would not need to do any tweaking > response we expect. It seems that in OAK, indexes are used to speed up > queries, but not as a complete information entity that must answer every > query clause. Well, I'm still figuring out the big picture of querying Yes the index may only be partially covering the query. So index job is to provide a super set of possible result paths and Query Engine would then evaluate the restriction for each path and at the repository state per current JCR Session (except fulltext constraints) Chetan Mehrotra
