[
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
