When searching in Enonic XP, you are searching for nodes, or content if working in the context of the CMS content API. This documentation is general and intended for the Storage, but except for some built-in property-values and the addition of some convenience parameters in the content domain, everything is valid for both domains.
In general, the search-APIs deal with a number of basic parameters:
Start & count¶
When searching, the result will contain a number of matching nodes. This number if given by the
count parameter in the query. The result will also contain a value indicating the total
number of hits for the search:
start parameter indicates from what position in the
result set we should start retrieving results.
Lets consider a search matching 1000 documents. Usually, one does not retrieve all these results at once, but rather a subset of the result - and fetch the next subset of the result if necessary. This type of data-retrieving is called paging.
Typically, one will decide the number of wanted results for each iteration, e.g 100:
- start = 0
- count = 100
Then, for the next iteration, we will start from the first result not retrieved in the first iteration:
- start = 100
- count = 100
total return field can be used to create page-navigation for the search result, by dividing
total hits by the page-size (
count) to get the needed number of pages.
The query-part of a search is where the constraints are defined. All nodes in the repository will match when then query parameter is empty. The query is defined in the Query Language section.
The results matching the query constraint will be assigned a score. This is imperative for fulltext-type queries. The score of a matching document depends on how the constraint is defined, e.g which fulltext-like function is used. See the Query Functions section for details.
Filter & query-filter¶
A filter also applies constraints. The difference between a filter-constraint and a query-constraint, is that the hits matching the filter are not scored. Scoring hits is a costly operation, and makes no sense for typical filter constraints like “price > 10”, so it’s a good way of optimizing searches by appending non-fulltext operations to the filter-constraint instead of the query-constraint.
There are also two different kinds of filters. A query-filter is a part of the query-constraint, meaning that aggregations results are also affected by these constraints. A filter on the other hand, is not considered in the aggregations calculations, meaning that applying a filter will not impact the aggregation result.