[ 
https://issues.apache.org/jira/browse/OAK-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14734841#comment-14734841
 ] 

Tommaso Teofili commented on OAK-3156:
--------------------------------------

I am currently more keen to vote for option 1.
I don't know all the history and could not find a significant wording in the 
JCR spec about preference of XPATH over SQL or viceversa. As far as I know both 
query languages should have the same powers/features/behaviors, at least in Oak 
(not taking into account performance optimizations).
For the specific case of suggest (and spellcheck) we currently respect the JR2 
syntax so we would need to document that from version x.y.z suggest / 
spellcheck queries has to be formulated / consumed in a different way.

> Lucene suggestions index definition can't be restricted to a specific type of 
> node
> ----------------------------------------------------------------------------------
>
>                 Key: OAK-3156
>                 URL: https://issues.apache.org/jira/browse/OAK-3156
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: lucene
>            Reporter: Vikas Saurabh
>            Assignee: Tommaso Teofili
>         Attachments: LuceneIndexSuggestionTest.java, OAK-3156-take2.patch, 
> OAK-3156.patch
>
>
> While performing a suggestor query like 
> {code}
> SELECT [rep:suggest()] as suggestion  FROM [nt:unstructured] WHERE 
> suggest('foo')
> {code}
> Suggestor does not provide any result. In current implementation, 
> [suggestions|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Suggestions]
>  in Oak work only for index definitions for {{nt:base}} nodetype.
> So, an index definition like:
> {code:xml}
>     <lucene-suggest
>         jcr:primaryType="oak:QueryIndexDefinition"
>         async="async"
>         compatVersion="{Long}2"
>         type="lucene">
>         <indexRules jcr:primaryType="nt:unstructured">
>             <nt:base jcr:primaryType="nt:unstructured">
>                 <properties jcr:primaryType="nt:unstructured">
>                     <description
>                         jcr:primaryType="nt:unstructured"
>                         analyzed="{Boolean}true"
>                         name="description"
>                         propertyIndex="{Boolean}true"
>                         useInSuggest="{Boolean}true"/>
>                 </properties>
>             </nt:base>
>         </indexRules>
>     </lucene-suggest>
> {code}
> works, but if we change nodetype to {{nt:unstructured}} like:
> {code:xml}
>     <lucene-suggest
>         jcr:primaryType="oak:QueryIndexDefinition"
>         async="async"
>         compatVersion="{Long}2"
>         type="lucene">
>         <indexRules jcr:primaryType="nt:unstructured">
>             <nt:unstructured jcr:primaryType="nt:unstructured">
>                 <properties jcr:primaryType="nt:unstructured">
>                     <description
>                         jcr:primaryType="nt:unstructured"
>                         analyzed="{Boolean}true"
>                         name="description"
>                         propertyIndex="{Boolean}true"
>                         useInSuggest="{Boolean}true"/>
>                 </properties>
>             </nt:base>
>         </indexRules>
>     </lucene-suggest>
> {code}
> , it won't work.
> The issue is that suggestor implementation essentially is passing a pseudo 
> row with path=/.:
> {code:title=LucenePropertyIndex.java}
>     private boolean loadDocs() {
> ...
>                         queue.add(new LuceneResultRow(suggestedWords));
> ...
> {code}
> and
> {code:title=LucenePropertyIndex.java}
>         LuceneResultRow(Iterable<String> suggestWords) {
>             this.path = "/";
>             this.score = 1.0d;
>             this.suggestWords = suggestWords;
>         }
> {code}
> Due to path being set to "/", {{SelectorImpl}} later filters out the result 
> as {{rep:root}} (primary type of "/") isn't a {{nt:unstructured}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to