- Use the Debug Panel
- Supported Browsers
- Use Two Versions of jQuery in the Same Page
- Identify the Version
- Enable Debug Information in the REST Queries
- Use the Relevance Inspector
- Use With the On-Premises Search API
- Prevent Queries Without Keywords
- Why Are Result Counts Inaccurate With Folding Enabled?
- Why Are Some Child Items Not Folded?
- Prevent Tab Captions From Being Cut Off
Why Are Result Counts Inaccurate With Folding Enabled?
This page assumes you have followed the appropriate steps to implement result folding on your page (see Folding Results).
If you enable result folding in your search page, you may notice that facet value result counts aren’t always accurate. Moreover, the total number of query results displayed by the
QuerySummary component might change when you load a new page of results using the
Pager component. These issues are caused by known index limitations.
Mismatching facet/query summary result counts can be explained by the fact that the index makes no distinction between child and parent results when evaluating facet value counts: both types of results are indiscriminately counted, if they match the Group By operation the facet relies on.
In a search page in which result folding is enabled, in the
Authorfacet, you select the
John Doevalue. This facet value indicates a result count of 12.
This result count, which has already been evaluated by the index, takes into account all results whose
@authorfield value is
John Doe, regardless of whether those results are parents or children in folding relationships.
QuerySummarycomponent states that the query you triggered by selecting the
John Doefacet value only returned 10 results.
In fact, two of the results which are included in the facet value result count were child results (replies, attachments, etc.). Those results have been folded under their respective parent when you triggered a query by selecting the
John Doefacet value. The
QuerySummarycount only includes the parent results of the folded relationships.
Mismatching pager/query summary result counts can be explained by the fact that the index only folds the requested page of results.
You send a query from a search page in which result folding is enabled. The result list displays 10 results per page.
A total of 35 unfolded results match the query. Suppose that 20 of those are parent results and 15 are child results. Since only 10 results were requested, the index only returns up to 10 folded results. For the sake of simplicity, assume that each of the first 10 results is a parent with a single folded child. This means that there are 15 unfolded results left (i.e., 35 unfolded results - (10 parent results + 10 child results)).
QuerySummarycomponent states that the query returned 25 results (the 10 currently displayed folded results + the 15 remaining unfolded results). Since the result list is displaying 10 results per page, 3 pages of results are currently available.
You interact with the
Pagercomponent to switch to the second page of results.
The index folds the next page of results. It folds 1 child result under each of the first 5 parent results. There are no more parent-child relationships to fold.
QuerySummarycomponent now states that there are 20 results (15 “folded” results + 5 results that don’t have children). The third page of results is gone.