honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/mapping/params.asciidoc

92 lines
2.1 KiB
Plaintext
Raw Normal View History

Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
[[mapping-params]]
== Mapping parameters
The following pages provide detailed explanations of the various mapping
parameters that are used by <<mapping-types,field mappings>>:
The following mapping parameters are common to some or all field datatypes:
* <<analyzer,`analyzer`>>
Change the field mapping index time boost into a query time boost. Index time boost will still be applied for indices created before 5.0.0.
2016-03-02 04:51:47 -05:00
* <<mapping-boost,`boost`>>
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
* <<coerce,`coerce`>>
* <<copy-to,`copy_to`>>
* <<doc-values,`doc_values`>>
* <<dynamic,`dynamic`>>
Add per-field metadata. (#50333) This PR adds per-field metadata that can be set in the mappings and is later returned by the field capabilities API. This metadata is completely opaque to Elasticsearch but may be used by tools that index data in Elasticsearch to communicate metadata about fields with tools that then search this data. A typical example that has been requested in the past is the ability to attach a unit to a numeric field. In order to not bloat the cluster state, Elasticsearch requires that this metadata be small: - keys can't be longer than 20 chars, - values can only be numbers or strings of no more than 50 chars - no inner arrays or objects, - the metadata can't have more than 5 keys in total. Given that metadata is opaque to Elasticsearch, field capabilities don't try to do anything smart when merging metadata about multiple indices, the union of all field metadatas is returned. Here is how the meta might look like in mappings: ```json { "properties": { "latency": { "type": "long", "meta": { "unit": "ms" } } } } ``` And then in the field capabilities response: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms" ] } } } } ``` When there are no conflicts, values are arrays of size 1, but when there are conflicts, Elasticsearch includes all unique values in this array, without giving ways to know which index has which metadata value: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms", "ns" ] } } } } ``` Closes #33267
2020-01-08 10:21:18 -05:00
* <<eager-global-ordinals,`eager_global_ordinals`>>
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
* <<enabled,`enabled`>>
* <<fielddata,`fielddata`>>
Add per-field metadata. (#50333) This PR adds per-field metadata that can be set in the mappings and is later returned by the field capabilities API. This metadata is completely opaque to Elasticsearch but may be used by tools that index data in Elasticsearch to communicate metadata about fields with tools that then search this data. A typical example that has been requested in the past is the ability to attach a unit to a numeric field. In order to not bloat the cluster state, Elasticsearch requires that this metadata be small: - keys can't be longer than 20 chars, - values can only be numbers or strings of no more than 50 chars - no inner arrays or objects, - the metadata can't have more than 5 keys in total. Given that metadata is opaque to Elasticsearch, field capabilities don't try to do anything smart when merging metadata about multiple indices, the union of all field metadatas is returned. Here is how the meta might look like in mappings: ```json { "properties": { "latency": { "type": "long", "meta": { "unit": "ms" } } } } ``` And then in the field capabilities response: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms" ] } } } } ``` When there are no conflicts, values are arrays of size 1, but when there are conflicts, Elasticsearch includes all unique values in this array, without giving ways to know which index has which metadata value: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms", "ns" ] } } } } ``` Closes #33267
2020-01-08 10:21:18 -05:00
* <<multi-fields,`fields`>>
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
* <<mapping-date-format,`format`>>
* <<ignore-above,`ignore_above`>>
* <<ignore-malformed,`ignore_malformed`>>
* <<index-options,`index_options`>>
Add pointer to the index-phrases option in shingle filter docs (#35771) We should be discouraging the use of shingle filters and instead pointing users to the index-phrases parameter on text fields.
2018-11-21 10:27:11 -05:00
* <<index-phrases,`index_phrases`>>
Improve docs for index_prefixes option (#35778) This commit moves the documentation and examples for the `index_prefixes` option on text fields to its own file, to bring it in line with other mapping parameters, and expands a bit on both.
2018-11-22 04:20:46 -05:00
* <<index-prefixes,`index_prefixes`>>
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
* <<mapping-index,`index`>>
Add per-field metadata. (#50333) This PR adds per-field metadata that can be set in the mappings and is later returned by the field capabilities API. This metadata is completely opaque to Elasticsearch but may be used by tools that index data in Elasticsearch to communicate metadata about fields with tools that then search this data. A typical example that has been requested in the past is the ability to attach a unit to a numeric field. In order to not bloat the cluster state, Elasticsearch requires that this metadata be small: - keys can't be longer than 20 chars, - values can only be numbers or strings of no more than 50 chars - no inner arrays or objects, - the metadata can't have more than 5 keys in total. Given that metadata is opaque to Elasticsearch, field capabilities don't try to do anything smart when merging metadata about multiple indices, the union of all field metadatas is returned. Here is how the meta might look like in mappings: ```json { "properties": { "latency": { "type": "long", "meta": { "unit": "ms" } } } } ``` And then in the field capabilities response: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms" ] } } } } ``` When there are no conflicts, values are arrays of size 1, but when there are conflicts, Elasticsearch includes all unique values in this array, without giving ways to know which index has which metadata value: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms", "ns" ] } } } } ``` Closes #33267
2020-01-08 10:21:18 -05:00
* <<mapping-field-meta,`meta`>>
* <<normalizer, `normalizer`>>
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
* <<norms,`norms`>>
* <<null-value,`null_value`>>
The name "position_offset_gap" is confusing because Lucene has three similar sounding things: * Analyzer#getPositionIncrementGap * Analyzer#getOffsetGap * IndexOptions.DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS and * FieldType#storeTermVectorOffsets Rename position_offset_gap to position_increment_gap closes #13056
2015-08-22 04:39:18 -04:00
* <<position-increment-gap,`position_increment_gap`>>
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
* <<properties,`properties`>>
* <<search-analyzer,`search_analyzer`>>
* <<similarity,`similarity`>>
* <<mapping-store,`store`>>
* <<term-vector,`term_vector`>>
include::params/analyzer.asciidoc[]
include::params/boost.asciidoc[]
include::params/coerce.asciidoc[]
include::params/copy-to.asciidoc[]
include::params/doc-values.asciidoc[]
include::params/dynamic.asciidoc[]
Reorganize docs of global ordinals. (#24982) Currently global ordinals are documented under `fielddata`. It moves them to their own file since they also work with doc values and fielddata is on the way out. Closes #23101
2017-06-01 10:47:44 -04:00
include::params/eager-global-ordinals.asciidoc[]
Add per-field metadata. (#50333) This PR adds per-field metadata that can be set in the mappings and is later returned by the field capabilities API. This metadata is completely opaque to Elasticsearch but may be used by tools that index data in Elasticsearch to communicate metadata about fields with tools that then search this data. A typical example that has been requested in the past is the ability to attach a unit to a numeric field. In order to not bloat the cluster state, Elasticsearch requires that this metadata be small: - keys can't be longer than 20 chars, - values can only be numbers or strings of no more than 50 chars - no inner arrays or objects, - the metadata can't have more than 5 keys in total. Given that metadata is opaque to Elasticsearch, field capabilities don't try to do anything smart when merging metadata about multiple indices, the union of all field metadatas is returned. Here is how the meta might look like in mappings: ```json { "properties": { "latency": { "type": "long", "meta": { "unit": "ms" } } } } ``` And then in the field capabilities response: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms" ] } } } } ``` When there are no conflicts, values are arrays of size 1, but when there are conflicts, Elasticsearch includes all unique values in this array, without giving ways to know which index has which metadata value: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms", "ns" ] } } } } ``` Closes #33267
2020-01-08 10:21:18 -05:00
include::params/enabled.asciidoc[]
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
include::params/fielddata.asciidoc[]
include::params/format.asciidoc[]
include::params/ignore-above.asciidoc[]
include::params/ignore-malformed.asciidoc[]
include::params/index.asciidoc[]
include::params/index-options.asciidoc[]
Add pointer to the index-phrases option in shingle filter docs (#35771) We should be discouraging the use of shingle filters and instead pointing users to the index-phrases parameter on text fields.
2018-11-21 10:27:11 -05:00
include::params/index-phrases.asciidoc[]
Improve docs for index_prefixes option (#35778) This commit moves the documentation and examples for the `index_prefixes` option on text fields to its own file, to bring it in line with other mapping parameters, and expands a bit on both.
2018-11-22 04:20:46 -05:00
include::params/index-prefixes.asciidoc[]
Add per-field metadata. (#50333) This PR adds per-field metadata that can be set in the mappings and is later returned by the field capabilities API. This metadata is completely opaque to Elasticsearch but may be used by tools that index data in Elasticsearch to communicate metadata about fields with tools that then search this data. A typical example that has been requested in the past is the ability to attach a unit to a numeric field. In order to not bloat the cluster state, Elasticsearch requires that this metadata be small: - keys can't be longer than 20 chars, - values can only be numbers or strings of no more than 50 chars - no inner arrays or objects, - the metadata can't have more than 5 keys in total. Given that metadata is opaque to Elasticsearch, field capabilities don't try to do anything smart when merging metadata about multiple indices, the union of all field metadatas is returned. Here is how the meta might look like in mappings: ```json { "properties": { "latency": { "type": "long", "meta": { "unit": "ms" } } } } ``` And then in the field capabilities response: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms" ] } } } } ``` When there are no conflicts, values are arrays of size 1, but when there are conflicts, Elasticsearch includes all unique values in this array, without giving ways to know which index has which metadata value: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms", "ns" ] } } } } ``` Closes #33267
2020-01-08 10:21:18 -05:00
include::params/meta.asciidoc[]
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
include::params/multi-fields.asciidoc[]
Add per-field metadata. (#50333) This PR adds per-field metadata that can be set in the mappings and is later returned by the field capabilities API. This metadata is completely opaque to Elasticsearch but may be used by tools that index data in Elasticsearch to communicate metadata about fields with tools that then search this data. A typical example that has been requested in the past is the ability to attach a unit to a numeric field. In order to not bloat the cluster state, Elasticsearch requires that this metadata be small: - keys can't be longer than 20 chars, - values can only be numbers or strings of no more than 50 chars - no inner arrays or objects, - the metadata can't have more than 5 keys in total. Given that metadata is opaque to Elasticsearch, field capabilities don't try to do anything smart when merging metadata about multiple indices, the union of all field metadatas is returned. Here is how the meta might look like in mappings: ```json { "properties": { "latency": { "type": "long", "meta": { "unit": "ms" } } } } ``` And then in the field capabilities response: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms" ] } } } } ``` When there are no conflicts, values are arrays of size 1, but when there are conflicts, Elasticsearch includes all unique values in this array, without giving ways to know which index has which metadata value: ```json { "latency": { "long": { "searchable": true, "aggreggatable": true, "meta": { "unit": [ "ms", "ns" ] } } } } ``` Closes #33267
2020-01-08 10:21:18 -05:00
include::params/normalizer.asciidoc[]
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
include::params/norms.asciidoc[]
include::params/null-value.asciidoc[]
The name "position_offset_gap" is confusing because Lucene has three similar sounding things: * Analyzer#getPositionIncrementGap * Analyzer#getOffsetGap * IndexOptions.DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS and * FieldType#storeTermVectorOffsets Rename position_offset_gap to position_increment_gap closes #13056
2015-08-22 04:39:18 -04:00
include::params/position-increment-gap.asciidoc[]
Docs: Mapping docs completely rewritten for 2.0
2015-08-06 11:24:29 -04:00
include::params/properties.asciidoc[]
include::params/search-analyzer.asciidoc[]
include::params/similarity.asciidoc[]
include::params/store.asciidoc[]
include::params/term-vector.asciidoc[]