Configuration : Configuring Search Queries : Using Prefix Handlers
 
Using Prefix Handlers
 
The Different Types of Prefix Handlers
Specify a Tokenization Configuration for Prefix Handlers
Prefix Handlers allow you to refine queries by targeting specific index fields or change the behavior of the query expansion.
For example, the title: prefix handler allows you to refine the search on document titles.
You use prefix handlers in UQL by prefixing your query with a given prefix, followed by colon (:) or a numerical comparison operator like >. For example, the 'title' prefix handler allows you to narrow the search on document titles, by looking only for matches within the 'title' index field.
Important: There must be a default prefix handler in your configuration. In the default configuration, this prefix handler is text. It is used as fallback when no prefix handler is specified in your UQL queries.
The Different Types of Prefix Handlers
Specify a Tokenization Configuration for Prefix Handlers
The Different Types of Prefix Handlers
This section describes the default types of prefix handlers available in Exalead CloudView. When adding prefix handlers, you have to select one of these types.
You can add prefix handlers of several types:
Type
Description
Text
Searches in alphanumeric fields (both static and dynamic ones).
There are several prefix handlers of Text type in the default configuration: text, trustedqueries, title, rawurl, document_pageurl_inurl
Numeric
Searches for numerical values in a numerical field (integer or double).
In the default configuration, the document_file_size prefix handler is of Numeric type.
Date
Searches for dates and times in a date field.
There are several prefix handlers of Date type in the default configuration: date, document_after, document_before, document_lastmodifieddate
By default, the input format is detected automatically. If you need to define a custom format, update the Input format field for your prefix handler in Search Logics > Query Language.
Category
Searches for paths in a category field.
There are several prefix handlers of Category type in the default configuration: datamodel_class, datamodel_class_hierarchy, corporate/tree, corporate/leaf, categories, source, language, etc.
Numeric (dynamic fields)
Searches for numerical values in a dynamic field.
Date (dynamic fields)
Searches for dates and times in a dynamic field.
Geographic
Defines the geographic field for WITHIN and DISTANCE searches.
Units of measurement
Searches for documents by resolving and converting values in the required unit of measurement.
For example, if volume is a Measure index field with a unit symbol set to ml, queries would look like:
• volume>25cl AND volume<16oz
• volume>250 (unit symbol is the default one, ml in our example)
The prefix handler detects the unit symbol if specified in the query, operates a conversion when required and then looks for properties according to the normalized numerical expression.
Linguistic options
Specifies a query expansion config on the prefix handler content, but does not perform search.
In the default configuration, the spellslike prefix handler is of Linguistic options type. You can also create a soundslike prefix handler if your want to find documents using the phonetic spelling of search terms.
Position
Searches in an alphanumeric field using the anchoring position (that is, restricting the match to be at a specific position).
Split
Searches for expressions, within the bounds of separators. For example, with a Split prefix handler named mypage with separator INPAGE, mypage:(a AND b) only matches if a and b appear on the same page in the document.
Site
Searches for parts of URLs.
There are several prefix handlers of Site type in the default configuration: document_pageurl_site, document_pageurl_url,
Similarity
Manually looks up similar values in documents.
Template
Template prefix handlers are used to rewrite the user original query (represented by the __QUERY__ variable) so that it targets dedicated index fields with a specific logic if required (typically OR/ AND operators, etc.).
For example, with a template set to:
<meta1>:__QUERY__ <OPERATOR> <meta2>:__QUERY__
we could have something like:
airport_name:__QUERY__ OR airport_city:__QUERY__
Important: You must consider __QUERY__ as a full UQL query string. Therefore, you cannot protect or encapsulat it with double quotes (") or single quotes (') characters, otherwise the variable will not be substituted. These UQL reserved words block the query expansion and make the query fail.
Important: If the original UQL query contains a prefix handler, it might lead to invalid UQL query interpretation. For example, if myTph template prefix handler is meta1:__QUERY__ OR meta2:__QUERY__ and the query input is myTph:date>30. Then the query template prefix handler interprets the query as meta1:date>30 OR meta2:date>30, which is not a valid UQL query and is rejected. A valid query input would be myTph:(foo or bar).
Important: There is a "default" prefix handler, which is used for query chunks, which have no explicit prefix handler. If this default prefix handler is a template prefix handler, then it is its duty to ensure that every single chunk of the query has an actual (that is, nontemplate) prefix handler after template expansion. Otherwise, you end up with meaningless query chunks. You cannot have DEF_TPH: ( file:__QUERY__ OR __QUERY__ )
Custom
Prefix handler implemented using custom Java code.
For more information, see "Add custom query processors or prefix handlers" in the Exalead CloudView Programmer's Guide.
Specify a Tokenization Configuration for Prefix Handlers
Each search logic needs a default tokenization that determines how prefix handlers break down user queries into tokens.
This section covers how to specify a specific tokenization configuration for search-time processing. To learn how to create new tokenization configs and specify them at index-time, see Customizing the Tokenization Config.
Specify Another Tokenization Config for a Search Logic
1. In the Administration Console, create a new default tokenization config as described in Customizing the Tokenization Config.
2. Specify this default tokenization config for:
◦ one or more semantic types, if using the Data Model to set up indexing. See Specify Another Tokenization Config in the Data Model
◦ and the analysis pipeline, if manually configuring processors. See Specify Another Tokenization Config for an Analysis Pipeline.
3. Go to Search > Search Logics > Your search logic > Query Language tab.
4. From the Default tokenization config list, select the new tokenization config.
5. Click Apply.
All prefix handlers use this tokenization config to tokenize queries.
Specify a Tokenization Config for a Prefix Handler
For metas that need to be tokenized differently than the default tokenization config, you can specify a different tokenization config for the prefix handlers targeting those metas.
1. In the Administration Console, create a new "exception" tokenization config as described in Customizing the Tokenization Config.
2. Specify this default tokenization config for the index mappings for metas that need to be tokenized differently. See Specify Another Tokenization Config for an Index Mapping.
3. Go to Search > Search Logics > Your search logic > Query Language tab.
4. Select the prefix handler for the appropriate meta.
5. From the Default tokenization config list, select the "exception" tokenization config you created in step 1.
6. Repeat for all the prefix handlers that need a different tokenization.
7. Click Apply.