[DOCS] Moved multi fields documentation into the core-types page
Removed docs about setting inheriting (was never added) Made mapping samples formatting similar as other ones.
This commit is contained in:
Martijn van Groningen
parent
2f910fbf7e
commit
75778d082b
|
|
@ -67,8 +67,6 @@ include::mapping/fields.asciidoc[]
|
|||
|
||||
include::mapping/types.asciidoc[]
|
||||
|
||||
include::mapping/multi-fields.asciidoc[]
|
||||
|
||||
include::mapping/date-format.asciidoc[]
|
||||
|
||||
include::mapping/dynamic-mapping.asciidoc[]
|
||||
|
|
|
|||
|
|
@ -6,5 +6,3 @@ include::mapping/date-format.asciidoc[]
|
|||
include::mapping/conf-mappings.asciidoc[]
|
||||
|
||||
include::mapping/meta.asciidoc[]
|
||||
|
||||
include::mapping/multi-fields.asciidoc[]
|
||||
|
|
|
|||
|
|
@ -1,120 +0,0 @@
|
|||
[[multi-fields]]
|
||||
== Multi Fields
|
||||
|
||||
The `fields` options allows to map several core types fields into a single
|
||||
json source field. This can be useful if a single field need to be
|
||||
used in different ways. For example a single field is to be used for both
|
||||
free text search and sorting.
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"tweet" : {
|
||||
"properties" : {
|
||||
"name" : {
|
||||
"type" : "string",
|
||||
"index" : "analyzed",
|
||||
"fields" : {
|
||||
"raw" : {"type" : "string", "index" : "not_analyzed"}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
In the above example the field name gets processed twice. The first time is gets
|
||||
processed as an analyzed string and this version is accessible under the field name
|
||||
`name`, this is the main field and is in fact just like any other field. The second time
|
||||
its get processed as a not analyzed string and is accessible under the name `name.raw`.
|
||||
|
||||
[float]
|
||||
=== Accessing Fields
|
||||
|
||||
The multi fields defined in the `fields` are prefixed with the
|
||||
name of the main field and can be accessed by their full path using the
|
||||
navigation notation: `name.raw`, or using the typed navigation notation
|
||||
`tweet.name.raw`. The `path` option allows to control how fields are accessed.
|
||||
If the `path` option is set to `full`, then the full path of the main field
|
||||
is prefixed, but if the `path` option is set to `just_name` the actual
|
||||
multi field name without any prefix is used. The default value for
|
||||
the `path` option is `full`.
|
||||
|
||||
The `just_name` setting, among other things, allows indexing content of multiple
|
||||
fields under the same name. In the example below the content of both fields
|
||||
`first_name` and `last_name` can be accessed by using `any_name` or `tweet.any_name`.
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"tweet" : {
|
||||
"properties": {
|
||||
"first_name": {
|
||||
"type": "string",
|
||||
"index": "analyzed",
|
||||
"path": "just_name",
|
||||
"fields": {
|
||||
"any_name": {"type": "string","index": "analyzed"}
|
||||
}
|
||||
},
|
||||
"last_name": {
|
||||
"type": "string",
|
||||
"index": "analyzed",
|
||||
"path": "just_name",
|
||||
"fields": {
|
||||
"any_name": {"type": "string","index": "analyzed"}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
=== Include in All
|
||||
|
||||
The `include_in_all` setting is ignored on any field that is defined in
|
||||
the `fields` options. Setting the `include_in_all` only makes sense on
|
||||
the main field, since the raw field value to copied to the `_all` field,
|
||||
the tokens aren't copied.
|
||||
|
||||
[float]
|
||||
=== Updating a field
|
||||
|
||||
In the essence a field can't be updated. However multi fields can be
|
||||
added to existing fields. This allows for example to have a different
|
||||
`index_analyzer` configuration in addition to the already configured
|
||||
`index_analyzer` configuration specified in the main and other multi fields.
|
||||
|
||||
Also the new multi field will only be applied on document that have been
|
||||
added after the multi field has been added and in fact the new multi field
|
||||
doesn't exist in existing documents.
|
||||
|
||||
Another important note is that new multi fields will be merged into the
|
||||
list of existing multi fields, so when adding new multi fields for a field
|
||||
previous added multi fields don't need to be specified.
|
||||
|
||||
[float]
|
||||
=== Inherit settings from main field
|
||||
|
||||
Any settings defined on the main field are automatically inherited by all
|
||||
multi fields and act as a default for a multi field.
|
||||
|
||||
The first example could also be defined as in the example below:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"tweet" : {
|
||||
"properties" : {
|
||||
"name" : {
|
||||
"type" : "string",
|
||||
"index" : "analyzed",
|
||||
"fields" : {
|
||||
"raw" : {"index" : "not_analyzed"}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
|
@ -666,4 +666,98 @@ The same mapping can be also defined using extended syntax:
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
===== Multi fields
|
||||
|
||||
The `fields` options allows to map several core types fields into a single
|
||||
json source field. This can be useful if a single field need to be
|
||||
used in different ways. For example a single field is to be used for both
|
||||
free text search and sorting.
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"tweet" : {
|
||||
"properties" : {
|
||||
"name" : {
|
||||
"type" : "string",
|
||||
"index" : "analyzed",
|
||||
"fields" : {
|
||||
"raw" : {"type" : "string", "index" : "not_analyzed"}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
In the above example the field name gets processed twice. The first time is gets
|
||||
processed as an analyzed string and this version is accessible under the field name
|
||||
`name`, this is the main field and is in fact just like any other field. The second time
|
||||
its get processed as a not analyzed string and is accessible under the name `name.raw`.
|
||||
|
||||
[float]
|
||||
==== Accessing Fields
|
||||
|
||||
The multi fields defined in the `fields` are prefixed with the
|
||||
name of the main field and can be accessed by their full path using the
|
||||
navigation notation: `name.raw`, or using the typed navigation notation
|
||||
`tweet.name.raw`. The `path` option allows to control how fields are accessed.
|
||||
If the `path` option is set to `full`, then the full path of the main field
|
||||
is prefixed, but if the `path` option is set to `just_name` the actual
|
||||
multi field name without any prefix is used. The default value for
|
||||
the `path` option is `full`.
|
||||
|
||||
The `just_name` setting, among other things, allows indexing content of multiple
|
||||
fields under the same name. In the example below the content of both fields
|
||||
`first_name` and `last_name` can be accessed by using `any_name` or `tweet.any_name`.
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"tweet" : {
|
||||
"properties": {
|
||||
"first_name": {
|
||||
"type": "string",
|
||||
"index": "analyzed",
|
||||
"path": "just_name",
|
||||
"fields": {
|
||||
"any_name": {"type": "string","index": "analyzed"}
|
||||
}
|
||||
},
|
||||
"last_name": {
|
||||
"type": "string",
|
||||
"index": "analyzed",
|
||||
"path": "just_name",
|
||||
"fields": {
|
||||
"any_name": {"type": "string","index": "analyzed"}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
==== Include in All
|
||||
|
||||
The `include_in_all` setting is ignored on any field that is defined in
|
||||
the `fields` options. Setting the `include_in_all` only makes sense on
|
||||
the main field, since the raw field value to copied to the `_all` field,
|
||||
the tokens aren't copied.
|
||||
|
||||
[float]
|
||||
==== Updating a field
|
||||
|
||||
In the essence a field can't be updated. However multi fields can be
|
||||
added to existing fields. This allows for example to have a different
|
||||
`index_analyzer` configuration in addition to the already configured
|
||||
`index_analyzer` configuration specified in the main and other multi fields.
|
||||
|
||||
Also the new multi field will only be applied on document that have been
|
||||
added after the multi field has been added and in fact the new multi field
|
||||
doesn't exist in existing documents.
|
||||
|
||||
Another important note is that new multi fields will be merged into the
|
||||
list of existing multi fields, so when adding new multi fields for a field
|
||||
previous added multi fields don't need to be specified.
|
||||
Loading…
Reference in New Issue