Skip to content
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.indexPattern][data.search.searchSource] Remove indexPattern.getComputedFields. #85162

Closed
Tracked by #166175
lukeelmers opened this issue Dec 7, 2020 · 3 comments
Labels
chore Feature:Data Views Data Views code and UI - index patterns before 8.0 Feature:Search Querying infrastructure in Kibana Icebox impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:DataDiscovery Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL. technical debt Improvement of the software architecture and operational architecture

Comments

@lukeelmers
Copy link
Member

Currently the index pattern class has a getComputedFields method which returns docvalue, stored, and scripted fields for a particular pattern. This method is only used by high level search (search source), and in discover.

Now that we've added support for the search fields API in search source, this method is less relevant and could probably be removed.

Here's a breakdown of each of the properties it returns and how they could be replaced:

1. docvalue fields
These were only used for ensuring that time fields were all requested in a format that Kibana understands (since ES supports more date formats than Kibana/momentjs knows how to parse). This was previously done using docvalue_fields, but since #82383 we are now requesting these formatted fields using the fields API. So getComputedFields().docvalueFields is still being used as a convenient way to access these fields, however the naming is confusing as it no longer has anything to do with docvalue fields.

Here's the logic that index patterns uses:

    const docvalueFields = reject(this.fields.getByType('date'), 'scripted').map(
      (dateField: any) => {
        return {
          field: dateField.name,
          format:
            dateField.esTypes && dateField.esTypes.indexOf('date_nanos') !== -1
              ? 'strict_date_time'
              : 'date_time',
        };
      }
    );

This could be moved into a different method or some type of static helper utility which is then used to retrieve all fields of type date with formats injected. e.g.

indexPattern.getFormattedDateFields() => Array<{ field: string; format: string }>
// or
getFormattedDateFields(fields: IndexPatternField[]) => Array<{ field: string; format: string}>

2. stored fields
We need to audit whether these are actually needed at all. getComputedFields always hardcodes this as ['*']. Search source will either request ['*'] or specific field names if the user provides them.

My understanding is that the fields API does not return stored fields, but we should test and determine whether we still need this feature at all in search source. Either way I don't think we really need it in getComputedFields

3. scripted fields
Search source could be switched over to using indexPattern.getScriptedFields instead, which is what getComputedFields does internally. There's no reason why we need to use getComputedFields for this.

cc @timroes @mattkime

@lukeelmers lukeelmers added Feature:Search Querying infrastructure in Kibana technical debt Improvement of the software architecture and operational architecture Feature:Data Views Data Views code and UI - index patterns before 8.0 Team:AppServices labels Dec 7, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-services (Team:AppServices)

@lukeelmers lukeelmers added chore loe:small Small Level of Effort labels Dec 7, 2020
@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:medium Medium Level of Effort and removed loe:small Small Level of Effort labels Jun 2, 2021
@exalate-issue-sync exalate-issue-sync bot added loe:small Small Level of Effort and removed loe:medium Medium Level of Effort labels Dec 21, 2021
@petrklapka petrklapka added Team:DataDiscovery Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL. and removed Team:AppServicesSv labels Nov 28, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

@kertal
Copy link
Member

kertal commented Oct 23, 2023

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.

@kertal kertal closed this as not planned Won't fix, can't repro, duplicate, stale Oct 23, 2023
@kertal kertal added the Icebox label Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Feature:Data Views Data Views code and UI - index patterns before 8.0 Feature:Search Querying infrastructure in Kibana Icebox impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:DataDiscovery Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL. technical debt Improvement of the software architecture and operational architecture
Projects
None yet
Development

No branches or pull requests

4 participants