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

pub trait KeywordMapping {
    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

fn analyzer() -> Option<&'static str>

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.

fn boost() -> Option<f32>

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

fn doc_values() -> Option<bool>

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.

fn eager_global_ordinals() -> Option<bool>

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.

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

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)
    }

fn include_in_all() -> Option<bool>

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.

fn ignore_above() -> Option<u32>

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

fn index() -> Option<bool>

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

fn index_options() -> Option<IndexOptions>

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

fn norms() -> Option<bool>

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

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

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

fn store() -> Option<bool>

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

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

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

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

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

Loading content...

Implementors

Loading content...