[
https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13746088#comment-13746088
]
Alex Parvulescu commented on OAK-828:
-------------------------------------
thanks Thomas for the detailed review!
overall I agree with the changes you proposed, and I applied some of them
directly.
What I'm looking at now is:
bq. creating a copy constructor "FilterImpl(Filter copy)"
this one I need right away as I'm still tweaking the code to cover more
usecases.
bq. The interface Rule: I guess it's there as a placeholder, to be used when
PropertyNameRule is added, right? What I would already try to do differently
is: currently Rule, is a marker interface, but could a "matches" method be
added, and the logic of SimpleNodeAggregator.getParents be changed to call this
method, instead of accessing the ChildNameRule object directly?
Very good point. This will be first on the list once I get the patch in, or
even before depending how things work out.
bq. There commented test "JCR-3160", why is it commented? If not implemented
yet, wouldn't it be possible to use @Ignore?
I inherited this from the jackrabbit test I copied over. I don't think it makes
sense to keep it, as the move scenario is not interesting anymore when you add
the parent as query time (before it meant that the parent needs to be
reindexed).
fyi what's still missing and important is to be able to run queries on the
child node like for example:
{code}
/jcr:root/content//element(*, nt:file)[(jcr:contains(jcr:content, 'dog'))]
{code}
and that's what I'm looking into now. My plan is to try to rewrite the query
somehow to query for the child node directly and then add the parent, similar
to what happens now for aggregates.
> 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
