[DOCS] Changed all store:yes/no to store:true/false

which is how this setting is stored internally
This commit is contained in:
Clinton Gormley 2013-11-07 16:56:59 +01:00
parent 566ca24247
commit 3465e69e83
17 changed files with 71 additions and 71 deletions

View File

@ -10,7 +10,7 @@ $ curl -XPUT 'http://localhost:9200/twitter/tweet/_mapping' -d '
{
"tweet" : {
"properties" : {
"message" : {"type" : "string", "store" : "yes"}
"message" : {"type" : "string", "store" : true }
}
}
}
@ -53,7 +53,7 @@ $ curl -XPUT 'http://localhost:9200/kimchy,elasticsearch/tweet/_mapping' -d '
{
"tweet" : {
"properties" : {
"message" : {"type" : "string", "store" : "yes"}
"message" : {"type" : "string", "store" : true }
}
}
}

View File

@ -44,7 +44,7 @@ $ curl -XPUT 'http://localhost:9200/twitter/tweet/_mapping' -d '
"tweet" : {
"dynamic": "strict",
"properties" : {
"message" : {"type" : "string", "store" : "yes"}
"message" : {"type" : "string", "store" : true }
}
}
}

View File

@ -33,7 +33,7 @@ Here is a sample mapping:
"type" : "object",
"dynamic" : false,
"properties" : {
"first" : {"type" : "string", "store" : "yes", "include_in_all" : false},
"first" : {"type" : "string", "store" : true , "include_in_all" : false},
"last" : {"type" : "string", "index" : "not_analyzed"}
}
},
@ -43,7 +43,7 @@ Here is a sample mapping:
"properties" : {
"first" : {
"properties" : {
"location" : {"type" : "string", "store" : "yes", "index_name" : "firstLocation"}
"location" : {"type" : "string", "store" : true, "index_name" : "firstLocation"}
}
},
"last" : {

View File

@ -17,7 +17,7 @@ using:
--------------------------------------------------
{
"tweet" : {
"_id" : {"index": "not_analyzed", "store" : "yes"}
"_id" : {"index": "not_analyzed", "store" : false }
}
}
--------------------------------------------------

View File

@ -8,7 +8,7 @@ data and explicit routing control is required.
==== store / index
The first thing the `_routing` mapping does is to store the routing
value provided (`store` set to `yes`) and index it (`index` set to
value provided (`store` set to `false`) and index it (`index` set to
`not_analyzed`). The reason why the routing is stored by default is so
reindexing data will be possible if the routing value is completely
external and not part of the docs.

View File

@ -20,7 +20,7 @@ In order to also store it, use:
--------------------------------------------------
{
"tweet" : {
"_size" : {"enabled" : true, "store" : "yes"}
"_size" : {"enabled" : true, "store" : true }
}
}
--------------------------------------------------

View File

@ -24,7 +24,7 @@ should be defined:
[float]
==== store / index
By default the `_timestamp` field has `store` set to `no` and `index`
By default the `_timestamp` field has `store` set to `false` and `index`
set to `not_analyzed`. It can be queried as a standard date field.
[float]

View File

@ -23,7 +23,7 @@ should be defined:
[float]
==== store / index
By default the `_ttl` field has `store` set to `yes` and `index` set to
By default the `_ttl` field has `store` set to `true` and `index` set to
`not_analyzed`. Note that `index` property has to be set to
`not_analyzed` in order for the purge process to work.

View File

@ -12,7 +12,7 @@ The `_type` field can be stored as well, for example:
--------------------------------------------------
{
"tweet" : {
"_type" : {"store" : "yes"}
"_type" : {"store" : true}
}
}
--------------------------------------------------

View File

@ -66,11 +66,11 @@ example:
{
"person" : {
"properties" : {
"file" : {
"file" : {
"type" : "attachment",
"fields" : {
"file" : {"index" : "no"},
"date" : {"store" : "yes"},
"date" : {"store" : true},
"author" : {"analyzer" : "myAnalyzer"}
}
}

View File

@ -52,7 +52,7 @@ more characters. An example mapping can be:
"properties" : {
"message" : {
"type" : "string",
"store" : "yes",
"store" : true,
"index" : "analyzed",
"null_value" : "na"
}
@ -76,8 +76,8 @@ The following table lists all the attributes that can be used with the
|`index_name` |The name of the field that will be stored in the index.
Defaults to the property/field name.
|`store` |Set to `yes` to store actual field in the index, `no` to not
store it. Defaults to `no` (note, the JSON document itself is stored,
|`store` |Set to `true` to store actual field in the index, `false` to not
store it. Defaults to `false` (note, the JSON document itself is stored,
and it can be retrieved from it).
|`index` |Set to `analyzed` for the field to be indexed and searchable
@ -105,7 +105,7 @@ fields.
options, possible values are `docs` (only doc numbers are indexed),
`freqs` (doc numbers and term frequencies), and `positions` (doc
numbers, term frequencies and positions). Defaults to `positions` for
`analyzed` fields, and to `docs` for `not_analyzed` fields. It
`analyzed` fields, and to `docs` for `not_analyzed` fields. It
is also possible to set it to `offsets` (doc numbers, term
frequencies, positions and offsets).
@ -186,14 +186,14 @@ numbered type:
|`index_name` |The name of the field that will be stored in the index.
Defaults to the property/field name.
|`store` |Set to `yes` to store actual field in the index, `no` to not
store it. Defaults to `no` (note, the JSON document itself is stored,
|`store` |Set to `true` to store actual field in the index, `false` to not
store it. Defaults to `false` (note, the JSON document itself is stored,
and it can be retrieved from it).
|`index` |Set to `no` if the value should not be indexed. Setting to
`no` disables `include_in_all`. If set to `no` the field can be stored
in `_source`, have `include_in_all` enabled, or `store` should be set to
`yes` for this to be useful.
`true` for this to be useful.
|`precision_step` |The precision step (number of terms generated for
each number value). Defaults to `4`.
@ -251,14 +251,14 @@ Defaults to the property/field name.
|`format` |The <<mapping-date-format,date
format>>. Defaults to `dateOptionalTime`.
|`store` |Set to `yes` to store actual field in the index, `no` to not
store it. Defaults to `no` (note, the JSON document itself is stored,
|`store` |Set to `true` to store actual field in the index, `false` to not
store it. Defaults to `false` (note, the JSON document itself is stored,
and it can be retrieved from it).
|`index` |Set to `no` if the value should not be indexed. Setting to
`no` disables `include_in_all`. If set to `no` the field can be stored
in `_source`, have `include_in_all` enabled, or `store` should be set to
`yes` for this to be useful.
`true` for this to be useful.
|`precision_step` |The precision step (number of terms generated for
each number value). Defaults to `4`.
@ -310,14 +310,14 @@ boolean type:
|`index_name` |The name of the field that will be stored in the index.
Defaults to the property/field name.
|`store` |Set to `yes` to store actual field in the index, `no` to not
store it. Defaults to `no` (note, the JSON document itself is stored,
|`store` |Set to `true` to store actual field in the index, `false` to not
store it. Defaults to `false` (note, the JSON document itself is stored,
and it can be retrieved from it).
|`index` |Set to `no` if the value should not be indexed. Setting to
`no` disables `include_in_all`. If set to `no` the field can be stored
in `_source`, have `include_in_all` enabled, or `store` should be set to
`yes` for this to be useful.
`true` for this to be useful.
|`boost` |The boost value. Defaults to `1.0`.
@ -405,36 +405,36 @@ to reload the fielddata using the new filters.
Posting formats define how fields are written into the index and how
fields are represented into memory. Posting formats can be defined per
field via the `postings_format` option. Postings format are configurable.
Elasticsearch has several builtin formats:
Elasticsearch has several builtin formats:
`direct`::
`direct`::
A postings format that uses disk-based storage but loads
its terms and postings directly into memory. Note this postings format
is very memory intensive and has certain limitation that don't allow
segments to grow beyond 2.1GB see \{@link DirectPostingsFormat} for
details.
details.
`memory`::
`memory`::
A postings format that stores its entire terms, postings,
positions and payloads in a finite state transducer. This format should
only be used for primary keys or with fields where each term is
contained in a very low number of documents.
contained in a very low number of documents.
`pulsing`::
`pulsing`::
A postings format in-lines the posting lists for very low
frequent terms in the term dictionary. This is useful to improve lookup
performance for low-frequent terms.
performance for low-frequent terms.
`bloom_default`::
`bloom_default`::
A postings format that uses a bloom filter to
improve term lookup performance. This is useful for primarily keys or
fields that are used as a delete key.
fields that are used as a delete key.
`bloom_pulsing`::
`bloom_pulsing`::
A postings format that combines the advantages of
*bloom* and *pulsing* to further improve lookup performance.
*bloom* and *pulsing* to further improve lookup performance.
`default`::
`default`::
The default Elasticsearch postings format offering best
general purpose performance. This format is used if no postings format
is specified in the field mapping.
@ -536,13 +536,13 @@ property, as this example shows:
}
--------------------------------------------------
The following Similarities are configured out-of-box:
The following Similarities are configured out-of-box:
`default`::
`default`::
The Default TF/IDF algorithm used by Elasticsearch and
Lucene in previous versions.
Lucene in previous versions.
`BM25`::
`BM25`::
The BM25 algorithm.
http://en.wikipedia.org/wiki/Okapi_BM25[See Okapi_BM25] for more
details.

View File

@ -13,12 +13,12 @@ type:
|`index_name` |The name of the field that will be stored in the index.
Defaults to the property/field name.
|`store` |Set to `yes` to store actual field in the index, `no` to not
store it. Defaults to `no` (note, the JSON document itself is stored,
|`store` |Set to `true` to store actual field in the index, `false` to not
store it. Defaults to `false` (note, the JSON document itself is stored,
and it can be retrieved from it).
|`index` |Set to `no` if the value should not be indexed. In this case,
`store` should be set to `yes`, since if it's not indexed and not
`store` should be set to `true`, since if it's not indexed and not
stored, there is nothing to do with it.
|`precision_step` |The precision step (number of terms generated for

View File

@ -210,7 +210,7 @@ mappings be stored, just set:
"store_generic" : {
"match" : "*",
"mapping" : {
"store" : "yes"
"store" : true
}
}
}

View File

@ -15,7 +15,7 @@ by a search hit. Defaults to load the internal `_source` field.
--------------------------------------------------
The fields will automatically load stored fields (`store` mapping set to
`yes`), or, if not stored, will load the `_source` and extract it from
`true`), or, if not stored, will load the `_source` and extract it from
it (allowing to return nested document object).
`*` can be used to load all stored fields from the document.

View File

@ -24,7 +24,7 @@ search hit (there will be another element in each search hit, called
fragments).
In order to perform highlighting, the actual content of the field is
required. If the field in question is stored (has `store` set to `yes`
required. If the field in question is stored (has `store` set to `true`
in the mapping) it will be used, otherwise, the actual `_source` will
be loaded and the relevant field will be extracted from it.
@ -66,7 +66,7 @@ a query match, effectively ignoring their positions.
==== Fast vector highlighter
If `term_vector` information is provided by setting `term_vector` to
If `term_vector` information is provided by setting `term_vector` to
`with_positions_offsets` in the mapping then the fast vector highlighter
will be used instead of the plain highlighter. The fast vector highlighter:

View File

@ -24,7 +24,7 @@ evaluation>> (based on different fields) for each hit, for example:
}
--------------------------------------------------
Script fields can work on fields that are not store (`my_field_name` in
Script fields can work on fields that are not stored (`my_field_name` in
the above case), and allow to return custom values to be returned (the
evaluated value of the script).
@ -40,7 +40,7 @@ type). Here is an example:
},
"script_fields" : {
"test1" : {
"script" : "_source.obj1.obj2"
"script" : "_source.obj1.obj2"
}
}
}

View File

@ -20,39 +20,39 @@ curl -XGET 'http://localhost:9200/twitter/tweet/1/_termvector?fields=text,...'
--------------------------------------------------
or adding by adding the requested fields in the request body (see
example below).
example below).
[float]
=== Return values
Three types of values can be requested: _term information_, _term statistics_
and _field statistics_. By default, all term information and field
and _field statistics_. By default, all term information and field
statistics are returned for all fields but no term statistics.
[float]
==== Term information
* term frequency in the field (always returned)
* term positions (`positions` : true)
* start and end offsets (`offsets` : true)
* term payloads (`payloads` : true), as base64 encoded bytes
* term frequency in the field (always returned)
* term positions (`positions` : true)
* start and end offsets (`offsets` : true)
* term payloads (`payloads` : true), as base64 encoded bytes
If the requested information wasn't stored in the index, it will be
omitted without further warning. See <<mapping-types,type mapping>>
for how to configure your index to store term vectors.
omitted without further warning. See <<mapping-types,type mapping>>
for how to configure your index to store term vectors.
[float]
==== Term statistics
Setting `term_statistics` to `true` (default is `false`) will
return
return
* total term frequency (how often a term occurs in all documents) +
* document frequency (the number of documents containing the current
term)
term)
By default these values are not returned since term statistics can
have a serious performance impact.
have a serious performance impact.
[float]
==== Field statistics
@ -60,11 +60,11 @@ have a serious performance impact.
Setting `field_statistics` to `false` (default is `true`) will
omit :
* document count (how many documents contain this field)
* document count (how many documents contain this field)
* sum of document frequencies (the sum of document frequencies for all
terms in this field)
terms in this field)
* sum of total term frequencies (the sum of total term frequencies of
each term in this field)
each term in this field)
[float]
=== Behaviour
@ -73,10 +73,10 @@ The term and field statistics are not accurate. Deleted documents
are not taken into account. The information is only retrieved for the
shard the requested document resides in. The term and field statistics
are therefore only useful as relative measures whereas the absolute
numbers have no meaning in this context.
numbers have no meaning in this context.
[float]
=== Example
=== Example
First, we create an index that stores term vectors, payloads etc. :
@ -89,7 +89,7 @@ curl -s -XPUT 'http://localhost:9200/twitter/' -d '{
"text": {
"type": "string",
"term_vector": "with_positions_offsets_payloads",
"store" : "yes",
"store" : true,
"index_analyzer" : "fulltext_analyzer"
},
"fullname": {
@ -129,7 +129,7 @@ curl -XPUT 'http://localhost:9200/twitter/tweet/1?pretty=true' -d '{
"fullname" : "John Doe",
"text" : "twitter test test test "
}'
curl -XPUT 'http://localhost:9200/twitter/tweet/2?pretty=true' -d '{
"fullname" : "Jane Doe",
"text" : "Another twitter test ..."
@ -141,7 +141,7 @@ The following request returns all information and statistics for field
[source,js]
--------------------------------------------------
curl -XGET 'http://localhost:9200/twitter/tweet/1/_termvector?pretty=true' -d '{
"fields" : ["text"],
"offsets" : true,
@ -156,7 +156,7 @@ Response:
[source,js]
--------------------------------------------------
{
"_id": "1",
"_index": "twitter",