Elastic App Search Meta Engines: A Comprehensive Guide

The primary advantage of employing a Meta Engine lies in its ability to provide a unified search experience over disparate data collections, each potentially having unique search configurations. This is crucial in large organizations where different business units or standalone sites might have specific relevance tunings, curations, or result settings tailored to their needs. A Meta Engine allows these specialized configurations to coexist within a broader, organization-wide search framework. Furthermore, Meta Engines play a role in managing permissions. While users with access to a Meta Engine gain read access to all its constituent Source Engines, this does not automatically grant write permissions to those Source Engines. This granular control ensures that data integrity is maintained across different units. In essence, Meta Engines enable the creation of a single source of truth for search, accommodating specialized requirements without sacrificing the coherence of an overarching search strategy. They allow for the implementation of organization-wide search priorities and curations that can differ from specific business-unit needs, offering a flexible and robust solution for complex search environments.

To ensure the effective utilization of Meta Engines, several key principles must be kept in mind: **Unified Schemas:** The schema of a Meta Engine is a composite of all its Source Engines' schemas. If two Source Engines share a field, their names must be identical. Differences in field names will result in them being treated as distinct fields. Crucially, these shared fields must also possess the same data type. Schema conflicts, where fields have the same name but different types, will lead to those fields being disabled. **Schema Changes Bubble Up:** Any modifications made to a Source Engine's schema, such as changing field names or types, will propagate to the Meta Engine. It is imperative to adapt any queries that rely on these specific fields or their types to reflect these changes. **Settings Changes Do Not Bubble Up:** Configurations like Curations, Relevance Tuning, or Result Settings applied at the Source Engine level will not automatically affect queries executed through the Meta Engine. These settings must be managed independently or applied at the Meta Engine level if a unified approach is desired. **Permissions:** Users granted access to a Meta Engine inherit read permissions to all documents accessible through that Meta Engine. Conversely, write permissions to a Meta Engine do not extend write access to the underlying Source Engines. **Read-Only Nature:** Meta Engines themselves do not store any documents. Consequently, document management and schema updates cannot be performed directly on a Meta Engine. These operations must always be carried out on the individual Source Engines.

The schema of a Meta Engine is a unified representation derived from the schemas of all its constituent Source Engines. This unified schema is visible on the Meta Engine's schema page, detailing the fields and their originating Source Engines. The way these schemas interact is critical, especially when conflicts arise. **Schema Field Type Conflicts:** A schema field type conflict occurs when two or more Source Engines define a field with the same name but assign it different data types. For example, if one engine has a 'visitors' field as 'text' and another has 'visitors' as 'number', this constitutes a conflict. In such cases, the conflicting field is completely disabled within the Meta Engine. This means it cannot be returned in search results, used for filtering, or for boosting, significantly limiting its utility. **Resolving a Schema Field Type Conflict:** To resolve a schema field type conflict, the user must navigate to the specific Source Engine where the conflicting field resides. Within that Source Engine's UI, the data type of the conflicting field needs to be updated to match the type used in the other Source Engines involved in the conflict. For instance, if 'visitors' is 'text' in one engine and 'number' in another, you would update one of them to match the other's type.

Within Meta Engines, documents are identified using a Scoped Document ID, a departure from the standard Document ID used in individual engines. A Scoped Document ID is constructed by concatenating the Engine Name and the original Document ID, separated by a pipe symbol ('|'). For example, if a document with ID 'park_shenandoah' resides in the 'eastern-national-parks' engine, its Scoped Document ID within a Meta Engine context would be 'eastern-national-parks|park_shenandoah'. This format is crucial to remember because it is required when interacting with certain API endpoints. For instance, the Curations endpoint for Meta Engines specifically requires a Document ID parameter, and in this context, you must provide the Scoped Document ID to correctly reference the document within its originating Source Engine.