-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Data Services] Support fields parameter in high level search apis #77241
Comments
Pinging @elastic/kibana-app-arch (Team:AppArch) |
with |
searchSource already has a |
currently:
elasticsearch says this in their docs:
so it seems we are doing everything correctly, the response should contain |
i am looking for this |
checked the response and it does contain fields array, but not with all the fields. |
could something like this work ? #77348 |
ES docs: https://www.elastic.co/guide/en/elasticsearch/reference/7.x/search-fields.html#search-fields In the docs it's referred to as "the fields parameter on a search request", but internally it's more often referred to as the "Fields API". The former is more accurate, but be aware of the latter because you'll probably hear it a lot. |
Many developers currently access field values directly from
_source
(this object is accessible in each hit from the hits array in a search request response). This exposes the raw source fields, which is often not actually what is desired. What is often desired is the mapped field values. This subtle difference leads to issues like this and this.Recently Elasticsearch has recently exposed a way to access these mapped field values.
The data search services needs to provide a way for developers to use this new search parameter, in order to solve problems like runtime field values showing up blank in discover.
There are some differences in values retrieved from _source vs the fields array:
There are performance considerations as well. If a searcher wants to get values for certain fields, maybe they want to turn _source off.
The bare minimum we'll need is the ability to allow users to define the list of fields returned in the fields array. Unfortunately an initial investigation revealed that it may not be straightforward to create a good DX, given that
searchSource.fields(..)
is already used for something else.Additional possibilities that probably don't need to be included in the initial API:
The text was updated successfully, but these errors were encountered: