I wanted to understand how AggregateIndex works and how it effects relative ranking of the final results
Consider a case where we search for "mountain is big" and have some NodeAggregation rules defined /jcr:root/content//element(*, test:Asset)[(jcr:contains(., 'mountain is big'))] Now as per (OAK-890) this would get broken into a full text expression which is and of 'mountain' , 'is', 'big' and AggregatedIndex would call the baseIndex (e.g LuceneIndex) with those specific terms. And AggregateCursor would then combine the result set. Assuming above interpretation is correct I have some queries 1. How would this manage result ordering as Lucene does not get a chance to see full expression. For e.g if there are 3 nodes A - Mountain is big B - Mountain is brown C - Big Ben I expect A to be shown at top. However the way AggregateIndex would merge the individual result it does not make use of scoring and results would be in some random order 2. Analysis - As the expression is interpreted at oak-core layer which is not aware of analyzer there would be a mismatch in the expected result. Lucene might be configured with analyzer with stopword like 'is' which it skips out but oak-core would not be aware 3. AggregationIndex and IntersectionCursor - The way cursors results are merged va intersection cursor there might be some data loss. The intersection cursor logic would only work if the actual cursor return result which are ordered by path. However cursor returned by LuceneIndex are order by jcr:score. So intersection logic might miss on some rows. Further it might have higher performance cost as Lucene has to do multiple runs. And supporting sorting would also be tricky Chetan Mehrotra
