Hello,
When using a native query clause the index plan, of the selected index,
does not include sorting capabilities although the index can. I'm not sure
if this is the expected result.
For example, using the next query:
/jcr:root/content/dam/store//element(*, dam:Asset)[*rep:native('myIndex',
'myProp:myValue')*] order by jcr:content/metadata/@sortableProp
The plan I get is:
{ costPerExecution : 1.0, costPerEntry : 50.0, estimatedEntryCount : 1,
filter : Filter(query=select [jcr:path], [jcr:score], * from [dam:Asset] as
a where native(a, 'myIndex', '*:*') ...order by
[jcr:content/metadata/sortableProp]
/..., isDelayed : true, isFulltextIndex : true, includesNodeData :
false, *sortOrder
: null*, definition : null, propertyRestriction : null, pathPrefix : }
Keeping in mind plan that the index defines the sortableProp as sortable:
oak:index
|_myIndex (functionName=myIndex)
|_indexRules
|_dam:Asset
|_properties
|_sortableProp* (ordered = true)*
Basically it is not clear why (the rationale behind)
org.apache.jackrabbit.oak.plugins.index.lucene.IndexPlanner.java returns
the planner when the query contains a function that matches and index
funtionName before adding the rest of the index capabilities to the plan.
Thus, the plan does not describe all the index capabilities (e.g. sort) and
when the query is performed through the LucenePropertyIndex I can't not
take advantage of it. Furthermore, what I can see executing the query is
that after retrieving a batch of documents from the index, they are
validated one by one, against all the query conditions, which is an
incredible amount of effort and waste of time as the lucene index was
defined to do all this tasks.
I guess that rewriting the query should avoid this situation, but not sure
how.
Regards
