[ 
https://issues.apache.org/jira/browse/SLING-11439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564308#comment-17564308
 ] 

Thomas Mueller commented on SLING-11439:
----------------------------------------

> option (limit 1000)

This is not actually needed. Instead, we can iterate over the result, counting 
the entries in the loop itself, and stop when needed.

> the query limit might be configured smaller

Currently the query limit is 100'000. I wouldn't know of a valid reason to 
configure a value below 1000. I recommend that we also test with 10'000 and see 
if that's faster. If it's much faster, then we can consider using 10'000 as 
well.

> the page size is smaller than the number of search results sharing the same 
> vanity path

I think the query should be:

{noformat}
select [sling:vanityPath], [sling:redirect], [sling:redirectStatus] from 
[nt:base]
where first([sling:vanityPath]) >= $lastEntry
order by first([sling:vanityPath]), [jcr:path]
{noformat}

That way, even if we have more than 1000 entries for the same vanity path, and 
the limit is smaller than 1000, it would work fine.

BTW we need "first(..)" because sling:vanityPath can be a multi-valued property.

> resource resolver: fails to detect aborted vanity path query
> ------------------------------------------------------------
>
>                 Key: SLING-11439
>                 URL: https://issues.apache.org/jira/browse/SLING-11439
>             Project: Sling
>          Issue Type: Bug
>          Components: ResourceResolver
>            Reporter: Julian Reschke
>            Priority: Major
>
> With the introduction of the Oak query limit, JCR queries may get aborted 
> when the result set size exceeds a certain value (currently by default 
> 100000).
> However:
> https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/604332e9be17378276685033bdbce54994dad8c1/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceIterator.java#L115-L134
> So Apache Sling JCR Resource's API hides that exception, and thus resource 
> resolver will happily startup with an incomplete cache.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to