> 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.
Yes this is as designed. The native query support in Lucene was implemented with the assumption that no other constraints are provided and all constraints are part of the query itself. So its not possible to mix native query with other JCR constraints currently > 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. This is done for following reasons 1. The index may not be handling all the expressed constraints 2. The index data may be out of sync with current session revision state. For e.g. if a property /a/b/@foo = bar was indexed at revision R1 and then it got changed to /a/b/@foo = baz in R2 (which is yet not indexed) then doing a query with session at R2 should not allow that path as part of final result set Chetan Mehrotra On Thu, Jun 22, 2017 at 7:12 PM, Alvaro Cabrerizo <[email protected]> wrote: > 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
