Trait elastic_types::string::keyword::mapping::KeywordMapping [−] [src]

pub trait KeywordMapping where
    Self: Default, {
    fn analyzer() -> Option<&'static str> { ... }

    fn boost() -> Option<f32> { ... }

    fn doc_values() -> Option<bool> { ... }

    fn eager_global_ordinals() -> Option<bool> { ... }

    fn fields() -> Option<BTreeMap<&'static str, StringField>> { ... }

    fn include_in_all() -> Option<bool> { ... }

    fn ignore_above() -> Option<u32> { ... }

    fn index() -> Option<bool> { ... }

    fn index_options() -> Option<IndexOptions> { ... }

    fn norms() -> Option<bool> { ... }

    fn null_value() -> Option<&'static str> { ... }

    fn store() -> Option<bool> { ... }

    fn search_analyzer() -> Option<&'static str> { ... }

    fn similarity() -> Option<&'static str> { ... }
}

The base requirements for mapping a string type.

Custom mappings can be defined by implementing KeywordMapping.

Examples

Define a custom KeywordMapping:

#[derive(Default)]
struct MyStringMapping;
impl KeywordMapping for MyStringMapping {
    //Overload the mapping functions here
    fn boost() -> Option<f32> {
        Some(1.5)
    }
}

This will produce the following mapping:

{
    "type": "keyword",
    "boost": 1.5
}

Provided Methods

The analyzer which should be used for analyzed string fields, both at index-time and at search-time (unless overridden by the search_analyzer). Defaults to the default index analyzer, or the standard analyzer.

Field-level index time boosting. Accepts a floating point number, defaults to 1.0.

Should the field be stored on disk in a column-stride fashion, so that it can later be used for sorting, aggregations, or scripting? Accepts true (default) or false.

Should global ordinals be loaded eagerly on refresh? Accepts true or false (default). Enabling this is a good idea on fields that are frequently used for (significant) terms aggregations.

Multi-fields allow the same string value to be indexed in multiple ways for different purposes, such as one field for search and a multi-field for sorting and aggregations, or the same string value analyzed by different analyzers.

Examples

Subfields are provided as simple structs, so you don't need to define a separate type to map them:

fn fields() -> Option<BTreeMap<&'static str, StringField>> {
        let mut fields = BTreeMap::new();

    //Add a `token_count` as a sub field
    fields.insert("count", StringField::TokenCount(
        ElasticTokenCountFieldMapping::default())
    );

    //Add a `completion` suggester as a sub field
    fields.insert("comp", StringField::Completion(
        ElasticCompletionFieldMapping::default())
    );

    Some(fields)
    }

Whether or not the field value should be included in the _all field? Accepts true or false. Defaults to false if index is set to no, or if a parent object field sets include_in_all to false. Otherwise defaults to true.

The maximum number of characters to index. Any characters over this length will be ignored.

Should the field be searchable? Accepts true (default) or false.

What information should be stored in the index, for search and highlighting purposes. Defaults to Positions.

Whether field-length should be taken into account when scoring queries. Accepts true (default) or false.

Accepts a string value which is substituted for any explicit null values. Defaults to null, which means the field is treated as missing.

Whether the field value should be stored and retrievable separately from the _source field. Accepts true or false (default).

The analyzer that should be used at search time on analyzed fields. Defaults to the analyzer setting.

Which scoring algorithm or similarity should be used. Defaults to "classic", which uses TF/IDF.

Implementors