elastic
elastic copied to clipboard
How to specify "fields" in Elasticsearch request "SearchSource" struct
Which version of Elastic are you using?
[x ] elastic.v7 (for Elasticsearch 7.x) [ ] elastic.v6 (for Elasticsearch 6.x) [ ] elastic.v5 (for Elasticsearch 5.x) [ ] elastic.v3 (for Elasticsearch 2.x) [ ] elastic.v2 (for Elasticsearch 1.x)
Please describe the expected behavior
I would like to achieve the following: https://www.elastic.co/guide/en/elasticsearch/reference/current/search-fields.html
However looking at the SearchSource struct I can only specify "doc_value" fields and "stored_fields" however I can't seem to find how to specify just "fields" field e.g. from the ES example:
POST my-index-000001/_search { "query": { "match": { "message": "foo" } }, "fields": ["user.id", "@timestamp"], "_source": false }
After further search I seem to find the answer (provided by @olivere in another thread https://www.elastic.co/guide/en/elasticsearch/reference/5.2/breaking_50_search_changes.html#_literal_fields_literal_parameter):
The fields parameter has been replaced by stored_fields. The stored_fields parameter will only return stored fields — it will no >longer extract values from the _source
However manually constructing the JSON struct and posting it directly to ES using curl works as expected using "fields" in Elastcisearch 7.x
As stated here, this feature is in beta and probably has not too much to do with the thread mentioned above. It's a bit like FetchSourceContext which allows to include/exclude certain fields, but with the benefit of what's being said in the 2nd paragraph.
Hey, checking to see if "fields" is still planning on being supported. There is a scenario that we must use fields instead of _source to avoid too_complex_to_determinize_exception. @olivere
This looks now stable and it seems it is also encouraged:
Using fields is typically better These options are usually not required. Using the fields option is typically the better choice, unless you absolutely need to force loading a stored or docvalue_fields.
It would be nice for #1625 to get merged.
Just chiming in that we could really use this too