Allow multiple field names/patterns for (path_)(un)match (#66364)

[quux00]

Arrays of patterns are now allowed for dynamic_templates in the match, unmatch, path_match and path_unmatch fields. DynamicTemplate has been modified to support List for these fields. The patterns can be either simple wildcards or regex. As with previous functionality, mixing of wildcards and regex will not throw an error, but will not work as expected at mapping time.

One new error pathway was added: if a user specifies a list of non-strings for one of these pattern fields (e.g., "match": [10, false]) a MapperParserException will be thrown.

Closes #66364.

[github-actions]

Documentation preview:

• ✨ Changed pages

[romseygeek]

This a great start, thanks @quux00 . I left a few suggestions.

[romseygeek]

One small comment, LGTM otherwise!

[romseygeek]

Yes, let's do this in a follow-up, no need to complicate this PR.

[elasticsearchmachine]

Pinging @elastic/es-search (Team:Search)

[javanna]

I believe we were previously calling toString here, which makes me suspect we may have accepted numbers and other things. Probably not a feature, but if that is the case changing it for single values may break existing dynamic templates? Could you verify this?

[quux00]

Yes, you are correct - it used to do a toString() on the JSON field (which is why an entry like ["foo", "bar"] was changed to the string "[\"foo"\, \"bar\"]" as noted by the original reporter of the request.

In this PR, I noted in the commit message that I changed that I added a new error case:

One new error pathway was added: if a user specifies a list of non-strings for one of these pattern fields (e.g., "match": [10, false]) a MapperParserException will be thrown.

Which is in this code block you highlighted:

       if (entry.getValue() instanceof String s) {
            matchList.add(s);
        } else if (entry.getValue() instanceof List<?> ls) {
            for (Object o : ls) {
                if (o instanceof String s) {
                    matchList.add(s);
                } else {
                    throw new MapperParsingException(
                        Strings.format("[%s] values must either be a string or list of strings, but was [%s]", propName, entry.getValue())
                    );
                }
            }
        } else {
            throw new MapperParsingException(
                Strings.format("[%s] values must either be a string or list of strings, but was [%s]", propName, entry.getValue())
            );
        }

Good point that this may be a breaking change. You are correct that numbers are accepted in 8.8 and before:

PUT my-index-000001
{
  "mappings": {
    "dynamic_templates": [
      {
        "mytemplate": {
          "match_pattern": "simple",
          "match": 12,
          "mapping": {
            "type": "keyword"
          }
        }
      }
    ]
  }
}

// the mapping gets converted to string
// here is the _mapping result
    "mappings": {
      "dynamic_templates": [
        {
          "mytemplate": {
            "match": "12",
            "mapping": {
              "type": "keyword"
            }
          }
        }
      ]
    }

So to not be a breaking change, the code logic here would need to be:

        if (entry.getValue() instanceof List<?> ls) {
            for (Object o : ls) {
                matchList.add(o.toString());
            }
        } else {
            matchList.add(entry.getValue().toString());
        }

Is that the recommended code change here?

[javanna]

we could consider being more strict when parsing from the array, and it would make sense to enforce a single type there, rather than calling toString blindly on all kinds of different types? I guess we are stuck with toString for the single element case? What do you think?

[quux00]

I think that's right. Since parsing ["foo", "bar"] as an array is new functionality, how we treat the elements in the array can be changed since that's new, but with the single element change, we might break things if we change. I'll make a new issue and change it. Good catch.