Limit multi fields to relevant settings

[rjernst]

Multi fields are more limited than regular fields. They cannot be object or nested types. There are also other settings like copy_to or include_in_all (any others?) that should not work. We should enforce this by rejecting these settings when parsed within a multi field.

[clintongormley]

+1

[clintongormley]

copy_to no longer works but include_in_all, fields and probably others do work - for clarity these should throw an exception

[paregos]

It looks like copy_to and include_in_all no longer work, is there a list of other fields that shouldn't work?
Sorry if I misunderstood your comment but did you mean if the propName is fields within a multiField it should be rejected like if the propName is include_in_all within a multiField?

Relevant file - https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/index/mapper/TypeParsers.java

[javanna]

@elastic/es-search-aggs

[jtibshirani]

It looks like almost all options that should be rejected now are:

• object and nested fields are rejected (Explicitly disallow multi fields from using object or nested fields #10745)
• copy_to is disallowed with a clear error message (throw exception if a copy_to is within a multi field #15213)
• as of 6.0, include_in_all is no longer a supported option

The last option that we may want to reject is fields, which would mean the user is defining multifields within a multifield. Although it seems a bit unusual, this is currently allowed and appears to work as expected. I wonder if we should just continue to allow the fields option, as it gives some flexibility without adding much complexity.

[jtibshirani]

After discussing internally, we decided we'd like to deprecate + remove support for chained multifields. I filed #41267 to track the issue and will close out this one.