Thanks chetan! I wish I had known "it is not possible to mix native query with other JCR constraints currently".
Regards. On Fri, Jun 23, 2017 at 10:29 AM, Chetan Mehrotra <[email protected] > wrote: > > 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 >
