Change of behavior with bool querry (empty should clause)

[ddre54]

When executing a bool query with an empty should array, there is a change in behavior from previous versions:

Consider this query:

POST /articles/_search
{
    "from": 0,
    "size": 100,
    "sort": [{"published_at": { "order": "desc"}}],
"query": {
    "filtered": {
       "query": {
       "bool": {
           "should": [

           ]
       }
       },
       "filter": {
           "and": {
              "filters": [
                 {"range": {
                    "published_at": {
                       "from": "now-3M/d",
                       "to": "now"
                    }
                 }},
                 {
                     "not": {
                        "filter": {
                            "terms": {
                               "_id": [
                                  "53fe1068c3b5a026a600002a",
                                  "53fe1068c3b5a026a600002a"
                               ]
                            }
                        }
                     }
                 }
              ]
           }
       }
    }
}
}

In version: Version: 1.2.1, Build: 6c95b75/2014-06-03T15:02:52Z, JVM: 1.7.0_51

The previous query will return this result:

{
   "took": 3,
   "timed_out": false,
   "_shards": {
      "total": 5,
      "successful": 5,
      "failed": 0
   },
   "hits": {
      "total": 0,
      "max_score": null,
      "hits": []
   }
}

Whereas from version: Version: 1.3.4, Build: a70f3cc/2014-09-30T09:07:17Z, JVM: 1.7.0_65
and above, it will give the following result:

{
   "took": 3,
   "timed_out": false,
   "_shards": {
      "total": 5,
      "successful": 5,
      "failed": 0
   },
   "hits": {
      "total": 15840,
      "max_score": null,
      "hits": [
         {
            "_index": "articles",
            "_type": "article",
            "_id": "5474bsebc3s5s015es00ss5d",
            "_score": null,
            "_source": {
               "categories": [],
               "created_at": "2014-11-25T17:35:39Z",
               "keywords": [
                  null,
                  null,
                  null,
                  null,
                  null,
                  null,
                  null,
                  null,
                  null
               ],
               "open_calais_keywords": [
                  "transport",
                  "private transport",
                  "land transport",
                  "sports cars",
                  "chevrolet corvette",
                  "muscle car",
                  "chevrolet",
                  "chevrolet corvette c5 z06",
                  "chevrolet corvette c6 zr1"
               ],
               "open_calais_topics": [],
               "override_topic": null,
               "published_at": "2014-11-25T23:22:01+00:00",
               "rss_feed_url": "http://page.com/source",
               "suitability_score": 0,
               "summary": "Useful summary here",
               "tags": [
                  "Chevrolet Corvette",
                  "Muscle car",
                  "Porsche 911",
                  "Midlife crisis",
                  "Italy"
               ],
               "title": "Chevrolet Readies the 2015 Corvette Z06",
               "topics": null,
               "oid": "5474bsebc3s5s015es00ss5d",
               "topic": null
            },
            "sort": [
               1416957721000
            ]
         }
      ]
   }
}

In previous versions of Elasticsearch, a bool query with an empty should array would return zero hits whereas in the latest version, an empty should array behaves as a match_all. Is this the intended behavior?

[clintongormley]

Hiya

Yes, this was a change made in 1.3.3. See #7240

[navneet-lyra]

Shouldn't we be able to toggle out of this behavior by using minimum_should_match?

I've noticed that if the minimum_should_match value > number of should clauses, then minimum_should_match is ignored. This seems like an unintended pitfall for systems where queries are programmatically generated (from query-understanding or otherwise).

[ddre54]

@clintongormley Thanks for clarifying this 👍