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.

See Also
Specify a Tokenization Configuration for Prefix Handlers
Code Samples to Create Similarity Query Prefix Handlers

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.