Schemas
Edit pageA schema is the definition of how a document, and the fields it contains, are stored and indexed. For instance, use schemas to define:
- which string fields should be treated as full text fields.
- which fields contain numbers, dates, or geolocations.
- which fields should be indexed globally.
- custom rules to control the typing for dynamically added fields.
Each field has a data type which can be:
- a simple type like
text,string,keyword,datetime,floatorboolean. - a sub-type which supports the hierarchical nature of JSON such as
objectorarray. - or a specialised type like
geospatial.
You can read more about field types here.
Field types do not need to be defined before being used. Thanks to dynamic typing, new field names will be added automatically, just by indexing a document. New fields can be added both to the top-level and to inner object and nested fields.
The dynamic typing rules can be configured to customize the type that is used for new fields.
You can read more about dynamic typing here.
You know more about your data than Xapiand can guess, so while dynamic typing can be useful to get started, at some point you will want to specify your own explicit types.
You can create field types when you create an index, and you can add fields to an existing index with the Create Index API.
You can read more about explicit types here.
Values can be explicitly converted from one compatible type to another during indexing, mirroring the casting available at search time.
You can read more about casting types here.
Numeric, date and geospatial fields index extra coarse-grained terms so that ranges and range aggregations are fast. The granularities are configurable.
You can read more about accuracy here.
Indexing mode defines what parts of the documents are indexed and how.
You can read more about this mode here.
Schemas can have custom meta data associated with it.
You can read more about meta data here.
Some times, field names are dynamic (e.g. every new document could be adding a different name for a field). In these cases, Dynamic Field Names make it so such field names do not add a new concrete field to the schema; and instead all those are added as if it was a single shared field.
You can read more about dynamic field names here.
Similarly to Dynamic Field Names, Namespaces reuse the field type, but these also allow nested field names to be added and searched.
You can read more about namespaces here and here.
When explicitly used, Foreign Schemas can establish where the schema information will be stored. For example, when a set of indexes all share the same schema it’d be beneficial to have a single shared schema. This can be accomplished by setting the foreign schema of all such indexes to point to a document containing the schema.
You can read more about Foreign Schemas here.
