I merged in the changes from clinton and updated some minor stuff in the docs. I also added some more test randomization. I think it's ready

+1, so many people on the mailing list have been hit by this "misunderstanding" of the multi-match query. The doc updates in this PR alone will help considerably! I love how you group the fields by analyzer without requiring the user to do it by hand (not that it is hard).

Is is going to be in 1.0? I only see a 1.1 tag.

What is the expected behaviour when (stupidly) querying across a combo of number and text fields? Currently get a NumberFormatException from parser on text search terms. Might user expect e.g. "37 the high street" to work on house number (numeric) and street name (text) fields without error?

@markharwood if the user specifies an analyzer for the query, then i would have expected this to work, but apparently it doesn't.

PUT /t/t/1
{
  "first_name": "will",
  "last_name": "smith",
  "count": 12
}

GET /_validate/query?explain
{
  "query": {
    "multi_match": {
      "query": "will smith 12",
      "fields": [
        "*_name",
        "count"
      ],
      "type": "cross_fields",
      "analyzer": "standard",
      "operator": "and"
    }
  }
}

returns an explanation of:

+blended("will", fields: [first_name, count, last_name]) 
+blended("smith", fields: [first_name, count, last_name]) 
+blended("12", fields: [first_name, count, last_name])

But it doesn't:

GET /_search
{
  "query": {
    "multi_match": {
      "query": "will smith 12",
      "fields": [
        "*_name",
        "count"
      ],
      "type": "cross_fields",
      "analyzer": "standard",
      "operator": "and"
    }
  }
}
# no results

@clintongormley I've tried specifying 'standard' analyzer and it looks like it doesn't get used because the mapping for integer fields doesn't want to use any analyzer on the input (due to IntegerFieldMapper.useTermQueryWithQueryString returns true). So the query string does not get tokenized for this field and IntegerFieldMapper just barfs on the full string "37 the high st" as an invalid number.
A long winded way of saying "this won't work"...
So we either needed to document the shortcomings or try fix.

@clintongormley @markharwood I just pushed a fix for the numeric problem your test should work now. I will pull this in if nobody objects.

@jpountz I fixed the last two comments and squashed after rebase to master. Can you take a last look?

@mattweber 1.0 is frozen we don't push features into it anymore. As you can guess GA is close so this will only be 1.1 but since we don't plan to wait too long with the next minor release I don't think this is too much of a bummer :)

+1!

@s1monw Just tried this again and was still getting java.lang.NumberFormatException: For input string: "song 2"
running this:

"query" :
{
      "multi_match" : {
             "query" : "song 2",
              "fields" : [ "Album", "Ignore2" ],
                "analyzer":"standard",
               "type":"cross_fields"
        },
}

This is on the musicbrainz dataset I shared where field "Album" is type string and "Ignore2" is type integer.

@markharwood can you confirm that last commit fixed your issues?

Following latest changes I can confirm that #5005 (comment) no longer throws exceptions and the logic for checking numeric fields works in my test

pushed to 1.x and master