From 94c1a7dabeeb5b5249944dd28e8b0437a1dc7f24 Mon Sep 17 00:00:00 2001 From: Martijn van Groningen Date: Tue, 11 Nov 2014 15:09:39 +0000 Subject: [PATCH] Docs: Fix incorrect documentation for the `index.query.parse.allow_unmapped_fields` setting. The `index.query.parse.allow_unmapped_fields` setting can't influence whether unmapped fields are allowed in alias filters and percolator queries. --- docs/reference/mapping/dynamic-mapping.asciidoc | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/docs/reference/mapping/dynamic-mapping.asciidoc b/docs/reference/mapping/dynamic-mapping.asciidoc index 86fb1d3ebe8..abcfbc650e1 100644 --- a/docs/reference/mapping/dynamic-mapping.asciidoc +++ b/docs/reference/mapping/dynamic-mapping.asciidoc @@ -67,12 +67,11 @@ root and inner object types: [float] === Unmapped fields in queries -Queries and filters can refer to fields which don't exist in a mapping, except -when registering a new <> or when creating -a <>. In these two cases, any fields referred to in -the query or filter must already exist in the mapping, otherwise there is a -chance that the wrong field type will be used. +Queries and filters can refer to fields that don't exist in a mapping. Whether this +is allowed is controlled by the `index.query.parse.allow_unmapped_fields` setting. +This setting defaults to `true`. Setting it to `false` will disallow the usage of +unmapped fields in queries. -This requirement can be disabled by setting -`index.query.parse.allow_unmapped_fields` to `true`, in which case you run the -risk that your query or filter might not work correctly. +When registering a new <> or creating +a <> then the `index.query.parse.allow_unmapped_fields` setting +is forcefully overwritten to disallowed unmapped fields. \ No newline at end of file