Glossary

This page explains some of the lingo specific to the Search API.

Index

A configuration object defining a set of data to be indexed. The index's settings determine what data is indexed (for example, which entity types, and which of their fields) and how it is indexed (for example, which data type should be used for a certain field, should searches on a field be case-sensitive, etc.). Also keeps track of which items still need to be indexed (or re-indexed, if they were updated). Needs to lie on a server in order to be really used (although configuration is independent of a server).

For example, you could have a "Node index" for indexing nodes. It would contain the fields that should be indexed and their types, the processors to use when indexing and searching and some other settings. The details of how to index data are independent of these settings, and server-specific.

Other modules that build functionality on top of the Search API (for example, by providing search pages) always reference the index as the source of the search data. This way, they, too, are independent of the inner mechanics of the search server.

Server

A concrete way to index and search data. It could, e.g., represent a certain database, a connection to an external search server, etc. How exactly the data is stored is determined by the server's backend plugin, but most Search API functionality is independent of this.

A server can have an arbitrary number of indexes attached to it, whose search data is then indexed on that server.

Backend

Identifies the type of server backend which is used for a server, thereby specifying how the data will be indexed and searched. For instance, there are backends available which will use databases, Solr servers, Xapian servers, MongoDB instances, etc., for indexing and searching data. When creating a server, a backend has to be chosen, which cannot be changed afterwards.

Note: Backends used to be called "Service classes" in the Drupal 7 version.

Datasource

A type of data which can be indexed by the Search API. Each index has to be associated with one or more datasources, which determine what kind of items will be indexed.

Most item types correspond to entity types with the same name (content, comments, users, taxonomy terms, …), but there can also be additional datasources defined by contrib modules which do not need to be entity types.

Property

A defined property of an item, like a node's title or a user's mail address. Additionally, properties can also be provided with processors. If a property is located on a related entity, not the originally indexed entity, the "property path" reflects all virtual "steps" that would be needed to get from the indexed entity to the property in question.

Field

Configuration on an index for a certain property that should be indexed. Multiple fields can be created for the same property, for example for indexing it with different data types.

Data type

Determines how a field is indexed. While "Fulltext" fields can be completely searched for keywords, other fields can only be used for filtering. They will also be converted to fit their respective value ranges.

How types other than "Fulltext" are handled depends on the backend used. Its documentation should state how the type-selection affects the indexed content. On the index's "Fields" tab you can review which types are supported by the current backend, and what fallback types are used for those that aren't.

Boost

Number determining how important a certain field is, when searching for fulltext keywords. The higher the value is, the more important the field. E.g., when the node title has a boost of 5.0 and the node body a boost of 1.0, keywords found in the title will increase the score (roughly) as much as five keywords found in the body. This has only an effect when the score is used (for sorting or other purposes). It has no effect on other parts of the search result.

Processor

An object that is used for preprocessing indexed data as well as search queries, and for postprocessing search results. E.g., processors can be used to make searches case-insensitive, to filter markup out of indexed content, etc., but also to add additional properties available for indexing.

Task

In the Search API, a “task” is a change that still needs to be executed. They are used either when operations (for instance, deleting items) fail on the search server (this might happen, for instance, when a Solr server cannot be reached temporarily), or when changes to the configuration take longer to apply and should therefore use a batch operation (for instance, when adding new datasources to an index). However, the system is extensible, so other modules could use it as well to “remember” search server- or index-specific operations that they would like to execute in a batch operation.
When tasks are present in the system, they can be executed either via the local action then visible on the Search API overview page, or via the buttons on the server or index “View” pages (to just execute tasks specific to that server or index).
Tasks are not to be confused with items needing to be indexed – the latter are tracked in a separate, dedicated table, search_api_item instead of the task system.