Skip to content

Commit

Permalink
[DOCS] Deprecated the path setting in favour of copy_to
Browse files Browse the repository at this point in the history
Relates to #4729
  • Loading branch information
clintongormley committed Feb 5, 2014
1 parent 4e9fa5c commit d9bdfe3
Show file tree
Hide file tree
Showing 3 changed files with 6 additions and 107 deletions.
46 changes: 3 additions & 43 deletions docs/reference/mapping/types/core-types.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -615,6 +615,7 @@ The following Similarities are configured out-of-box:
details.


[[copy-to]]
[float]
===== Copy to field

Expand Down Expand Up @@ -681,48 +682,6 @@ processed as an analyzed string and this version is accessible under the field n
`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

Expand All @@ -745,4 +704,5 @@ 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.
previous added multi fields don't need to be specified.

65 changes: 1 addition & 64 deletions docs/reference/mapping/types/object-type.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -168,74 +168,11 @@ For example:

In the above, `name` and its content will not be indexed at all.

[float]
==== path

In the <<mapping-core-types,core_types>>
section, a field can have a `index_name` associated with it in order to
control the name of the field that will be stored within the index. When
that field exists within an object(s) that are not the root object, the
name of the field of the index can either include the full "path" to the
field with its `index_name`, or just the `index_name`. For example
(under mapping of _type_ `person`, removed the tweet type for clarity):

[source,js]
--------------------------------------------------
{
"person" : {
"properties" : {
"name1" : {
"type" : "object",
"path" : "just_name",
"properties" : {
"first1" : {"type" : "string"},
"last1" : {"type" : "string", "index_name" : "i_last_1"}
}
},
"name2" : {
"type" : "object",
"path" : "full",
"properties" : {
"first2" : {"type" : "string"},
"last2" : {"type" : "string", "index_name" : "i_last_2"}
}
}
}
}
}
--------------------------------------------------

In the above example, the `name1` and `name2` objects within the
`person` object have different combination of `path` and `index_name`.
The document fields that will be stored in the index as a result of that
are:

[cols="<,<",options="header",]
|=================================
|JSON Name |Document Field Name
|`name1`/`first1` |`first1`
|`name1`/`last1` |`i_last_1`
|`name2`/`first2` |`name2.first2`
|`name2`/`last2` |`name2.i_last_2`
|=================================

Note, when querying or using a field name in any of the APIs provided
(search, query, selective loading, ...), there is an automatic detection
from logical full path and into the `index_name` and vice versa. For
example, even though `name1`/`last1` defines that it is stored with
`just_name` and a different `index_name`, it can either be referred to
using `name1.last1` (logical name), or its actual indexed name of
`i_last_1`.

More over, where applicable, for example, in queries, the full path
including the type can be used such as `person.name.last1`, in this
case, both the actual indexed name will be resolved to match against the
index, and an automatic query filter will be added to only match
`person` types.

[float]
==== include_in_all

`include_in_all` can be set on the `object` type level. When set, it
propagates down to all the inner mapping defined within the `object`
that do no explicitly set it.

2 changes: 2 additions & 0 deletions docs/reference/migration/migrate_1_0.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -353,4 +353,6 @@ in the query string.
been removed. You can use the
<<function-score-instead-of-boost,`function_score`>> instead.

* The `path` parameter in mappings has been deprecated. Use the
<<copy-to,`copy_to`>> parameter instead.

0 comments on commit d9bdfe3

Please sign in to comment.