[
https://issues.apache.org/jira/browse/SLING-11439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564308#comment-17564308
]
Thomas Mueller edited comment on SLING-11439 at 7/8/22 2:58 PM:
----------------------------------------------------------------
> 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. BUT you need to make sure
you don't use "limit 1000", and read all the entries for a given value.
> 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. E.g.
{noformat}
lastEntry = "";
while (true) {
it = query("select [sling:vanityPath], [sling:redirect],
[sling:redirectStatus] " +
"from [nt:base] where first([sling:vanityPath]) >= $lastEntry " +
"order by first([sling:vanityPath]), [jcr:path]", lastEntry);
for (int i = 0; it.hasNext(); i++) {
String x = it.next().get("[sling:vanityPath]");
if (i > 1000 && !x.equals(lastEntry)) {
// next page
lastEntry = x;
break;
}
... remember x (in the Bloom filter) ...
}
}
{noformat}
BTW we need "first(..)" because sling:vanityPath can be a multi-valued property.
was (Author: tmueller):
> 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. E.g.
{noformat}
for (int i = 0; i < 1000 && it.hasNext(); i++)
{noformat}
> 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)
