[DOCS] Fixed typos and corrected grammar
This commit is contained in:
parent
cdc7dfbb2c
commit
87246af256
|
@ -20,14 +20,14 @@ API, unless otherwise specified.
|
|||
[[multi-index]]
|
||||
== Multiple Indices
|
||||
|
||||
Most APIs that refer to an `index` paramter support execution across multiple indices,
|
||||
Most APIs that refer to an `index` parameter support execution across multiple indices,
|
||||
using simple `test1,test2,test3` notation (or `_all` for all indices). It also
|
||||
support wildcards, for example: `test*`, and the ability to "add" (`+`)
|
||||
and "remove" (`-`), for example: `+test*,-test3`.
|
||||
|
||||
All multi indices API support the `ignore_indices` option. Setting it to
|
||||
`missing` will cause indices that do not exists to be ignored from the
|
||||
execution. By default, when its not set, the request will fail.
|
||||
execution. By default, when it's not set, the request will fail.
|
||||
|
||||
NOTE: Single index APIs such as the <<docs>> and the
|
||||
<<indices-aliases,single-index `alias` APIs>> do not support multiple indices.
|
||||
|
|
|
@ -10,7 +10,7 @@ Note, this is different compared to creating a `filtered` query with the
|
|||
filter, since this will cause the facets to only process the filtered
|
||||
results.
|
||||
|
||||
For example, lets create two tweets, with two different tags:
|
||||
For example, let's create two tweets, with two different tags:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
@ -50,7 +50,7 @@ curl -XPOST 'localhost:9200/twitter/_search?pretty=true' -d '
|
|||
--------------------------------------------------
|
||||
|
||||
We get two hits, and the relevant facets with a count of 1 for both
|
||||
`green` and `blue`. Now, lets say the `green` facet is chosen, we can
|
||||
`green` and `blue`. Now, let's say the `green` facet is chosen, we can
|
||||
simply add a filter for it:
|
||||
|
||||
[source,js]
|
||||
|
@ -74,5 +74,5 @@ curl -XPOST 'localhost:9200/twitter/_search?pretty=true' -d '
|
|||
|
||||
And now, we get only 1 hit back, but the facets remain the same.
|
||||
|
||||
Note, if additional filters is required on specific facets, they can be
|
||||
Note, if additional filters are required on specific facets, they can be
|
||||
added as a `facet_filter` to the relevant facets.
|
||||
|
|
|
@ -46,15 +46,15 @@ type). Here is an example:
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
Note the `_source` keyword here to navigate the json like model.
|
||||
Note the `_source` keyword here to navigate the json-like model.
|
||||
|
||||
Its important to understand the difference between
|
||||
It's important to understand the difference between
|
||||
`doc['my_field'].value` and `_source.my_field`. The first, using the doc
|
||||
keyword, will cause the terms for that field to be loaded to memory
|
||||
(cached), which will result in faster execution, but more memory
|
||||
consumption. Also, the `doc[...]` notation only allows for simple valued
|
||||
fields (can't return a json object from it) and make sense only on non
|
||||
analyzed or single term based fields.
|
||||
fields (can't return a json object from it) and make sense only on
|
||||
non-analyzed or single term based fields.
|
||||
|
||||
The `_source` on the other hand causes the source to be loaded, parsed,
|
||||
and then only the relevant part of the json is returned.
|
||||
|
|
Loading…
Reference in New Issue