[
https://issues.apache.org/jira/browse/OAK-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu reassigned OAK-944:
-----------------------------------
Assignee: Alex Parvulescu
> Full-text index aggregation
> ---------------------------
>
> Key: OAK-944
> URL: https://issues.apache.org/jira/browse/OAK-944
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
> Reporter: Thomas Mueller
> Assignee: Alex Parvulescu
>
> Jackrabbit 2.x supports index aggregates as documented here:
> http://wiki.apache.org/jackrabbit/IndexingConfiguration#Index_Aggregates
> Jackrabbit Oak should support this feature as well.
> There are multiple way to implement it:
> * Aggregate the data when indexing. This is what Jackrabbit 2.x does. The
> disadvantage is that if filtering is needed (see also JCR-3611), then this
> needs to be done at indexing time; and filtering at query time might be hard
> to achieve.
> * Aggregate the data when querying. In this case, filtering can be
> implemented at query execution time.
> Alex, Marcel and me yesterday briefly discussed the options and came to the
> conclusion that we try use the second approach for Oak, that is, aggregate
> the data when querying. One way to achieve that is by adding a new
> FulltextQueryIndex which does the filtering and aggregation. This index
> internally uses a FulltextQueryIndex similar to how the NodeTypeIndex uses a
> PropertyIndex. This "aggregating full-text index" can then be used for any
> kind of full-text index (Lucene, Solr,...).
> To allow more flexibility in aggregate filtering, we will extend the Filter
> interface to allow reading from the repository (using the Tree interface).
--
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
