mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-06 21:18:31 +00:00
Adds infrastructure so `gradle :docs:check` will extract tests from snippets in the documentation and execute the tests. This is included in `gradle check` so it should happen on CI and during a normal build. By default each `// AUTOSENSE` snippet creates a unique REST test. These tests are executed in a random order and the cluster is wiped between each one. If multiple snippets chain together into a test you can annotate all snippets after the first with `// TEST[continued]` to have the generated tests for both snippets joined. Snippets marked as `// TESTRESPONSE` are checked against the response of the last action. See docs/README.asciidoc for lots more. Closes #12583. That issue is about catching bugs in the docs during build. This catches *some* bugs in the docs during build which is a good start.
73 lines
2.1 KiB
Plaintext
73 lines
2.1 KiB
Plaintext
[[mapping-store]]
|
|
=== `store`
|
|
|
|
By default, field values are <<mapping-index,indexed>> to make them searchable,
|
|
but they are not _stored_. This means that the field can be queried, but the
|
|
original field value cannot be retrieved.
|
|
|
|
Usually this doesn't matter. The field value is already part of the
|
|
<<mapping-source-field,`_source` field>>, which is stored by default. If you
|
|
only want to retrieve the value of a single field or of a few fields, instead
|
|
of the whole `_source`, then this can be achieved with
|
|
<<search-request-source-filtering,source filtering>>.
|
|
|
|
In certain situations it can make sense to `store` a field. For instance, if
|
|
you have a document with a `title`, a `date`, and a very large `content`
|
|
field, you may want to retrieve just the `title` and the `date` without having
|
|
to extract those fields from a large `_source` field:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT my_index
|
|
{
|
|
"mappings": {
|
|
"my_type": {
|
|
"properties": {
|
|
"title": {
|
|
"type": "text",
|
|
"store": true <1>
|
|
},
|
|
"date": {
|
|
"type": "date",
|
|
"store": true <1>
|
|
},
|
|
"content": {
|
|
"type": "text"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
PUT my_index/my_type/1
|
|
{
|
|
"title": "Some short title",
|
|
"date": "2015-01-01",
|
|
"content": "A very long content field..."
|
|
}
|
|
|
|
GET my_index/_search
|
|
{
|
|
"fields": [ "title", "date" ] <2>
|
|
}
|
|
--------------------------------------------------
|
|
// AUTOSENSE
|
|
<1> The `title` and `date` fields are stored.
|
|
<2> This request will retrieve the values of the `title` and `date` fields.
|
|
|
|
[NOTE]
|
|
.Stored fields returned as arrays
|
|
======================================
|
|
|
|
For consistency, stored fields are always returned as an _array_ because there
|
|
is no way of knowing if the original field value was a single value, multiple
|
|
values, or an empty array.
|
|
|
|
If you need the original value, you should retrieve it from the `_source`
|
|
field instead.
|
|
|
|
======================================
|
|
|
|
Another situation where it can make sense to make a field stored is for those
|
|
that don't appear in the `_source` field (such as <<copy-to,`copy_to` fields>>).
|