[
https://issues.apache.org/jira/browse/JCRVLT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933782#comment-17933782
]
Julian Reschke edited comment on JCRVLT-789 at 3/10/25 11:46 AM:
-----------------------------------------------------------------
The complicated part is to determine whether a filter path indeed requires
regexp matching - so we not only need to check whether something *is* a regexp
syntactically, but also whether the expression *needs* to be processed as
regexp.
For instance
{code}
a\.b
{code}
parses aas regexp, but would only match
{code}
a.b
{code}
was (Author: reschke):
The complicated part is to determine where a filter path indeed requires regexp
matching - so we not only need to check whether something *is* a regexp
syntactically, but also whether the expression *needs* to be processed as
regexp.
For instance
{code}
a\.b
{code}
parses aas regexp, but would only match
{code}
a.b
{code}
> AggregateImpl might be able to avoid iterating over sibling nodes
> -----------------------------------------------------------------
>
> Key: JCRVLT-789
> URL: https://issues.apache.org/jira/browse/JCRVLT-789
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Major
>
> See
> [https://github.com/apache/jackrabbit-filevault/blob/367ffb423d84993c5bb0eb0186f810a58b6227be/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/AggregateImpl.java#L696]
>
> This code currently iterates unconditionally over child nodes (which is a
> problem for large collections). We might be able to avoid that by checking
> the filters before descending.
> I tried a quick hack, and that made tests fail (which is good).
> Will continue with a test case first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
