[
https://issues.apache.org/jira/browse/OAK-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956359#comment-13956359
]
Thomas Mueller commented on OAK-1654:
-------------------------------------
> cursorToSet
The patch eagerly fetches the whole result using "cursorToSet" and puts it in a
set to do "Sets.intersection". There are two problems:
* cursorToSet only reads the path. This will break the new jcr:score() feature
(see LuceneIndex.LucenePathCursor).
* iterating should be done lazily while reading, in the same way as it's done
elsewhere, to avoid out of memory and to speed up cases where the user only
reads a part of the result.
If you want, I can have a look at that and propose a new patch.
> so the lucene index will be picked up and the aggregation won't work ...
> This can be fixed by making sure the 2 are not present at the same time
I think that's a good idea.
I think the following code should be changed:
{noformat}
if (constraint == null) {
return 10000;
}
{noformat}
to
{noformat}
if (constraint == null) {
throw new IllegalArgumentException();
}
{noformat}
> Composite index aggregates
> --------------------------
>
> Key: OAK-1654
> URL: https://issues.apache.org/jira/browse/OAK-1654
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-lucene, query
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Fix For: 0.20
>
> Attachments: OAK-1654.patch
>
>
> This is a followup for what is still missing from OAK-828: composite
> aggregates.
> This covers 2 parts:
> - when searching for 2 tokens that can be present on 2 different nodes, the
> common aggregated parent doesn't show up
> - when adding together multiple contains clauses on different hierarchy
> levels: now the lucene index simply returns an infinite cost.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
