Mark exists-query dsl doc properly

All the docs for the `exists` query that aren't marked as `CONSOLE`
aren't actually `CONSOLE`-worthy so this marks them as `NOTCONSOLE`.

It also rewrites the text around `missing` query. Since it was
removed in 5.0 we don't need to talk about it in the 6.0 docs.

Relates to #18160
This commit is contained in:
Nik Everett 2017-03-30 22:01:07 -04:00
parent 5f91241f57
commit bc33753aee
2 changed files with 19 additions and 7 deletions

View File

@ -107,7 +107,6 @@ buildRestTests.expectedUnconvertedCandidates = [
'reference/modules/scripting/security.asciidoc',
'reference/modules/scripting/using.asciidoc',
'reference/modules/cross-cluster-search.asciidoc', // this is hard to test since we need 2 clusters -- maybe we can trick it into referencing itself...
'reference/query-dsl/exists-query.asciidoc',
'reference/query-dsl/function-score-query.asciidoc',
'reference/query-dsl/geo-shape-query.asciidoc',
'reference/search/field-stats.asciidoc',

View File

@ -24,6 +24,7 @@ For instance, these documents would all match the above query:
{ "user": ["jane"] }
{ "user": ["jane", null ] } <3>
--------------------------------------------------
// NOTCONSOLE
<1> An empty string is a non-`null` value.
<2> Even though the `standard` analyzer would emit zero tokens, the original field is non-`null`.
<3> At least one non-`null` value is required.
@ -37,6 +38,7 @@ These documents would *not* match the above query:
{ "user": [null] } <2>
{ "foo": "bar" } <3>
--------------------------------------------------
// NOTCONSOLE
<1> This field has no values.
<2> At least one non-`null` value is required.
<3> The `user` field is missing completely.
@ -50,11 +52,21 @@ instance, if the `user` field were mapped as follows:
[source,js]
--------------------------------------------------
"user": {
"type": "text",
"null_value": "_null_"
PUT /example
{
"mapping": {
"doc": {
"properties": {
"user": {
"type": "text",
"null_value": "_null_"
}
}
}
}
}
--------------------------------------------------
// CONSOLE
then explicit `null` values would be indexed as the string `_null_`, and the
following docs would match the `exists` filter:
@ -64,6 +76,7 @@ following docs would match the `exists` filter:
{ "user": null }
{ "user": [null] }
--------------------------------------------------
// NOTCONSOLE
However, these docs--without explicit `null` values--would still have
no values in the `user` field and thus would not match the `exists` filter:
@ -73,11 +86,12 @@ no values in the `user` field and thus would not match the `exists` filter:
{ "user": [] }
{ "foo": "bar" }
--------------------------------------------------
// NOTCONSOLE
==== `missing` query
'missing' query has been removed because it can be advantageously replaced by an `exists` query inside a must_not
clause as follows:
There isn't a `missing` query. Instead use the `exists` query inside a
`must_not` clause as follows:
[source,js]
--------------------------------------------------
@ -97,4 +111,3 @@ GET /_search
// CONSOLE
This query returns documents that have no value in the user field.