Inconsistent usage pattern of SearchSourceBuilder

[fhopf]

The usage pattern for constructing some of the subsections of a search request using the SearchSourceBuilder is different, e.g. query, postFilter, facets, aggregations can be build by passing in the binary content or a Map. For highlighting and suggestions there are only methods to retrieve the current builder and use it to customize the query.

The clojure client Elastisch relies on the methods that accept Maps. That is why there doesn't seem to be support for highlighting and suggestions using the native client in Elastisch, only for the REST API.

Besides the problem with the clojure client I also think it would be nice to have a consistent interface.

Related issue in Elastisch:
clojurewerkz/elastisch#82

[michaelklishin]

In general, method overloads that accept source as a map make it much more convenient to use ES Java client from Clojure.

[javanna]

With #13859 we made a big step towards parsing the search request on the coordinating node. Effectively if you use the java api you can't specify a string or bytes array or map anymore when building a search request, as you need a structured java object instead, which is now natively streamable for communication between the nodes. This is why we removed all of the set methods that accepted string, bytes array, maps etc. from SearchSourceBuilder and SearchRequest. Those ones could only work knowing that parsing is delayed to each data node, which is not the case anymore in the master branch (future 3.0 release). That said I am closing this as won't fix, as the set methods that accept maps have all been removed.