Default to match_all instead of query_string

[lukasolson]

Fixes #12097.

This PR simply changes the default query from

{
  "query_string": {
    "query": "*"
  }
}

to

{
  "match_all": {}
}

In certain cases, this helps the first query to return much faster, which means you can get to exploring your data without having to wait.

[weltenwort]

jenkins, test this

[weltenwort]

Maybe the test case names should be updated to reflect the change.

[weltenwort]

the test failure looks unrelated, rebasing on master might fix it

[trevan]

If you save a dashboard with no filter in it (so that it uses the default match_all) and then re-open the dashboard, it will have a match_all filter in the filter bar.

I think that is happening because getFilterBarsForDashboard in https://github.com/lukasolson/kibana/blob/2368e67031425440b03bd1c9dbe71330922136f1/src/core_plugins/kibana/public/dashboard/filter_utils.js#L48 isn't removing the default match_all filter.

[Bargs]

Instead of trying to update this at the view layer, what if we transformed * query_string queries into a match_all at query generation time? We already have a fallback condition for this in _abstract. This would have the advantage of avoiding Trevan's issue, it ensures we never send a slow * query, and it's a much simpler change since it doesn't muck with stuff that's stored in app state.

[Bargs]

I also just remembered, we need to recognize that this is a breaking change for people who have a default_field set. With a default field set * will find all docs where that field exists instead of doing a match_all. So I don't know if we should do this in a minor. Perhaps fixing the performance issue is the lesser of two evils.

[lukasolson]

As @Bargs mentioned, there is the fallback condition in _abstract. This is why, when you first load Kibana, you'll actually get a { "match_all": {} } query. However, as soon as you hit the search button, or even navigate away from discover then back to discover, you'll get a {"query_string": { "query": "*" } } query.

We talked about this and ultimately decided to go with the following:

When you first load discover, the default query will remain { "match_all": {} }. As long as you haven't entered anything into the query bar, you'll get a { "match_all": {} } query. We will remove this condition, which means that for existing searches where the query is {"query_string": { "query": "*" } }, the user will now see * in the query bar, instead of an empty input. This is important for users who have a default_field set in their index, or in their query string options, because they may actually want to limit the search results to where the value for the default field exists.

This will make the behavior more intuitive and reliable, with less implicit behavior.

[trevan]

@lukasolson, don't remove that condition about the '*'. It was added to both ensure that the help text was visible and to prevent users from accidentally typing in a regex. #10272 and #10565 are both related to it.

[lukasolson]

@trevan, remember the discussion we had awhile back about the default query being a match_all? If the default query actually is a match_all and not *, then what's the harm in not hiding the query if it's *?

The difference in behavior will only be apparent to users with existing saved searches where the query is *. The problem is that users may actually want to run a wildcard query, and right now we swallow the user input in this case, so they don't know they're actually running a wildcard query. It's confusing behavior.

[trevan]

@lukasolson, if I add something to the query and then blank it out, will it go to match_all or to *? If to match_all, then that might be fine.

You'll want to add some "breaking changes" or something to indicate that people need to go back through all their saved searches and change it from * to blank. Otherwise, they will start seeing * again when they currently don't see it and people might, once again, run regex searches.

[lukasolson]

@trevan I'm proposing that if a user blanks it out, then it will be a match_all. The problem we had before is that it would automatically insert the *, even if you emptied it out, which caused the problems you're mentioning. And yeah, we should probably make a note of it in the release/upgrade notes.