[jira] [Comment Edited] (OAK-828) Full-text support for index aggregates

["Thomas Mueller (JIRA)" <ji...@apache.org>]

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

Thomas Mueller edited comment on OAK-828 at 9/10/13 9:41 AM:
-------------------------------------------------------------

I think one case that is not solved yet is if there are multiple constraints combined with "and" or "or", for example:

{code}
contains([text], 'hello') or contains([text], 'world')
{code}

Both "hello" and "world" could be in different nodes. I will write a test case.


With relative properties, I think I understand now what the problem is. Currently, the query

{code}
contains([node1/text], 'hello')
{code}

ignores the relative path in the {{LuceneIndex}} and returns {{/testroot/node1, /testroot/node3}} instead of just {{/testroot}}, which would be the correct result.

Now if relative properties are supported in {{LuceneIndex}} (as it used to be), this will break index aggregation for the following case: if the data is in fact stored in {{/testroot/node1/jcr:content}}, the {{LuceneIndex}} would incorrectly not return the data because it's not {{/node1}}.

Possibly the easiest solution to support this is that the AggregateIndex takes care of relative properties: it "flattens" the condition for the {{LuceneIndex}}, and filters the result (return {{/testroot}} instead of {{/testroot/node1}}. This should solve the problem, but I'm not quite sure how to implement it yet :-)

                
      was (Author: tmueller):
    I think one case that is not solved yet is if there are multiple constraints combined with "and" or "or", for example:

{code}
contains([text], 'hello') or contains([text], 'world')
{code}

Both "hello" and "world" could be in different sub-trees. I will write a test case.


With relative properties, I think I understand now what the problem is. Currently, the query

{code}
contains([node1/text], 'hello')
{code}

ignores the relative path in the {{LuceneIndex}} and returns {{/testroot/node1, /testroot/node3}} instead of just {{/testroot}}, which would be the correct result.

Now if relative properties are supported in {{LuceneIndex}} (as it used to be), this will break index aggregation for the following case: if the data is in fact stored in {{/testroot/node1/jcr:content}}, the {{LuceneIndex}} would incorrectly not return the data because it's not {{/node1}}.

Possibly the easiest solution to support this is that the AggregateIndex takes care of relative properties: it "flattens" the condition for the {{LuceneIndex}}, and filters the result (return {{/testroot}} instead of {{/testroot/node1}}. This should solve the problem, but I'm not quite sure how to implement it yet :-)

                  
> Full-text support for index aggregates
> --------------------------------------
>
>                 Key: OAK-828
>                 URL: https://issues.apache.org/jira/browse/OAK-828
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: oak-lucene, query
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>         Attachments: aggregates.patch
>
>
> There's no support for indexing aggregates in Oak [0]
> I'd like to start slowly rolling some basic support in, so that at least assumptions like fulltext search on files work properly.
> [0] http://wiki.apache.org/jackrabbit/IndexingConfiguration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira