[
https://issues.apache.org/jira/browse/SLING-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355697#comment-17355697
]
Konrad Windszus edited comment on SLING-10447 at 6/2/21, 1:05 PM:
------------------------------------------------------------------
Look at https://jackrabbit.apache.org/oak/docs/query/lucene.html#include-exclude
bq. Note that excludedPaths and includedPaths does not affect the index
selection logic for a query i.e. if a query has any path restriction specified
then that would not be checked against the excludedPaths and includedPaths.
So the answer to your question is yes (given that the index with the path
restriction is selected for the query based on its score)
was (Author: kwin):
Look at https://jackrabbit.apache.org/oak/docs/query/lucene.html#include-exclude
bq. Note that excludedPaths and includedPaths does not affect the index
selection logic for a query i.e. if a query has any path restriction specified
then that would not be checked against the excludedPaths and includedPaths.
So the answer to your question is yes.
> sling:vanityPath are being searched during startup in the entire repository,
> including version storage
> ------------------------------------------------------------------------------------------------------
>
> Key: SLING-10447
> URL: https://issues.apache.org/jira/browse/SLING-10447
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.7.6
> Reporter: Henry Kuijpers
> Priority: Major
> Fix For: Resource Resolver 1.7.8
>
>
> We have a lot of pages on our production author instance. We also have a lot
> of pages that use sling:vanityPath. Everytime a page is replicated, a new
> version is created.
> We have roughly 168.000 pages in our instance. In the /content node, there
> are approx. 4500 pages with vanity URLs. In the version storage, however,
> there are 120.000+ entries that have a sling:vanityPath defined.
> When starting up Apache Sling, the Resource Resolver fetches all the existing
> sling:vanityPath entries, which it fails to do, because of the large amount
> of sling:vanityPath in the version storage.
> In the code, I specifically see checks (when processing the query results)
> about the version storage. However, this should have been put inside the
> query as a filter, in order to avoid fetching such a large amount of query
> result nodes:
> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/4406b8fed0fedb48202fc6472fb552c36aa06e35/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1158
> I propose to update the query with a "not isdescendantnode"-check, to make
> sure we do not return any content from the version storage and thus make the
> default query limits of 100.000 nodes work again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
