As said before Search API has normalization of parameters and responses, this allows us to make one piece of code making a search request to an connection of type we don't know, to a engine we don't care about, and be sure it will work.
To ease the process of creating generic request, Search API has different classes with well defined parameters
SearchRequest
This request is one of the parameters expected by engine methods (search, multi_search, async_search and knn_search). SearchRequest holds all the possible parameters this methods could need, the implementation of this parameters depend on the engine specific implementation, and not all parameters are shared amongst all the methods
Property | Description | Default | Type | Required |
|---|---|---|---|---|
q | Query String | "*" | string | No |
query | Accepts the search query structure in the specific engine's format | object | No | |
knn | Accepts the knn search structure in the the specific engine's format | object | No | |
rescore | The query rescorer executes a second query only on the Top-K results returned. Expected in the specific engine's format | object | No | |
size | Defines the number of hits to return | integer (minimum: 0) | No | |
start | Starting document offset. Needs to be non-negative | integer (minimum: 0) | No | |
scroll | Period to retain the search context for scrolling | string | No | |
sort | Engine string definition or generic SortEntry defining the sort order | array of objects | No | |
fetch_fields | List of fields to return in the response based on field values | array of strings | No | |
default_operator | The default operator for the query string query: AND or OR | "or" | string | No |
highlight | Highlighters enable you to get highlighted snippets from one or more fields in your search results so you can show users where the query matches are | object | No | |
filters | Tuple of engine-specific filters. The tuple must contain optional_negated_filters, optional_filters, required_negated_filters, required_filters | No | ||
agg_filters | Tuple of engine-specific filters. The tuple must contain optional_negated_filters, optional_filters, required_negated_filters, required_filters | object | No | |
aggs | List of engine-specific aggregation implementations | object | No | |
exclude_fields | List of fields to exclude in the response based on field values | array of strings | No |
If you have a keen eye you notice several parameters are simple object types, opening up to a wide variety of options what it can receive, all this options are expecting engine specific format. This was done on purpose to allow the developer to tweak with the queries before sending them to the engine, to compensate for this non-agnostic approach Search API has agnostic tools
Flexibility and Customization: The use of simple object types as parameters allows for a wide range of options, enabling developers to customize queries to their specific needs.
Pre-Engine Query Tweaking: Developers have greater control over their queries, adjusting parameters to achieve desired search results and optimize the search experience, and maximizing the engine's capabilities.
Agnostic Tools for Compatibility: Agnostic tools bridge different search engines, ensuring code compatibility and easy integration without major modifications.
Prepare Data
For Q, Query and KNN
For the string parameter q, one approach available is the use of PyQPL, this library can translate query string to engine specific queries, here an example
This method allows you to have access to the QPLQuery, which can be manipulated (for information on this please check PYQPL space), and/or access to the engine specific query, and modify, inject or remove as desired. Then this query made from q, can be used in the parameters for query or knn
For Highlight
The highlight generation is as simple as calling the engine to which you will be sending the request and ask it to generate the highlight structure using the function generate_highlight
For Filters
Same as highlight, you can ask the engine to generate the filters (this is why the class FilterFactory is important), using the function generate_filters, this function receives a list_of_filters which is composed of DynamicFilters or JSON representations of it.
This will generate a SearchFilters which has the ability to merge with other SearchFilters, this way you can merge multiple filters from different sources into one single SearchFilters
For Aggregations
Repeating the pattern, you can also ask the engine to generate the aggregations (this is why the class AggregationFactory is important), using the function generate_aggregations, this function receives alist_of_aggregations which is composed of . Regarding selected aggregations (what happens when an aggregation is selected from ui), the structure is a list of SelectionAgg, or the JSON representation of a SelectionAgg, this list can be transformed into filters using the function generate_aggregation_filters wihch recieves the list of aggregations and the list of selected aggregations
Making the Actual Request
SortEntry
| Property | Description | Type | Required |
|---|---|---|---|
| field | Name of the field which will be used for sorting | string | Yes |
| display_name | Display name for this sort entry. Only applicable for the user interface | string | No |
| order | Sort order to be used. It can be one of the predefined SortOrder values or a custom object with additional properties | string or object | Yes |
SortOrder
An enumeration.
| Value | Description |
|---|---|
| asc | Ascending sort order |
| desc | Descending sort order |
Search Filters
SearchFilters is a normalization structure to hold all the filters to be applied into the search engine, and categorize each filter by behavior| Property | Description | Default | Type | Required |
|---|---|---|---|---|
| should_not | Filter which will act as a boolean operator NOR | [] | array of objects | No |
| should | Filter which will act as a boolean operator OR | [] | array of objects | No |
| must_not | Filter which will act as a boolean operator NAND | [] | array of objects | No |
| must | Filter which will act as a boolean operator AND | [] | array of objects | No |
| post_should_not | Filter which will act as a boolean operator NOR | [] | array of objects | No |
| post_should | Filter which will act as a boolean operator OR | [] | array of objects | No |
| post_must_not | Filter which will act as a boolean operator NAND | [] | array of objects | No |
| post_must | Filter which will act as a boolean operator AND | [] | array of objects | No |
Selection Aggregation
SelectionAgg is a normalization structure to hold all the filters to be applied into the search engine, and categorize each filter by behavior
| Property | Description | Default | Type | Required |
|---|---|---|---|---|
| id | Aggregation Id | string | Yes | |
| negated | List of values or ranges, depending on the aggregation, selected to filter by exclusion | [] | array | No |
| values | List of values or ranges, depending on the aggregation, selected to filter by | [] | array | No |
| level | Level of Deepness | 0 | integer | No |
Example Configuration: $action.getHelper().renderConfluenceMacro("$codeS$body$codeE")
Overview
Content Tools