[Discover] Reduce number of request for fields when switching a data view in Discover #147744
Labels
Feature:Data Views
Data Views code and UI - index patterns before 8.0
Feature:Discover
Discover Application
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
loe:needs-research
This issue requires some research before it can be worked on or estimated
performance
Team:DataDiscovery
Discover App Team (Document Explorer, Saved Search, Surrounding documents, Graph)
Projects
Comments
kertal
added
Feature:Discover
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
kertal
added
loe:needs-research
mattkime
added a commit
that referenced
this issue
Dec 22, 2022
## Summary Looking at why Discover was loading data view field lists were loading more than needed, I found more reasons than actual field list loads occurring but I think they're all deserving of improvement. - Discover was loading the default data view to see if there was an existing data view. We can rely on the `hasData` api instead. - We were loading a data view and then refreshing the field list. If the data view was being loaded fresh, its meant the field list was loaded twice. Field list refresh has been integrated into the dataViews api. - We were loading a data view, checking it if was adhoc, and tossing it if it wasn't. Now we keep the reference. Previously on page load, discover would make 3 calls to `fields_for_wildcard`, now it makes two. It loads all the field with one request and it makes an additional request where it applies the current filter to find relevant fields. Closes #147744
pgayvallet
pushed a commit
to pgayvallet/kibana
that referenced
this issue
Dec 22, 2022
## Summary Looking at why Discover was loading data view field lists were loading more than needed, I found more reasons than actual field list loads occurring but I think they're all deserving of improvement. - Discover was loading the default data view to see if there was an existing data view. We can rely on the `hasData` api instead. - We were loading a data view and then refreshing the field list. If the data view was being loaded fresh, its meant the field list was loaded twice. Field list refresh has been integrated into the dataViews api. - We were loading a data view, checking it if was adhoc, and tossing it if it wasn't. Now we keep the reference. Previously on page load, discover would make 3 calls to `fields_for_wildcard`, now it makes two. It loads all the field with one request and it makes an additional request where it applies the current filter to find relevant fields. Closes elastic#147744
crespocarlos
pushed a commit
to crespocarlos/kibana
that referenced
this issue
Dec 23, 2022
## Summary Looking at why Discover was loading data view field lists were loading more than needed, I found more reasons than actual field list loads occurring but I think they're all deserving of improvement. - Discover was loading the default data view to see if there was an existing data view. We can rely on the `hasData` api instead. - We were loading a data view and then refreshing the field list. If the data view was being loaded fresh, its meant the field list was loaded twice. Field list refresh has been integrated into the dataViews api. - We were loading a data view, checking it if was adhoc, and tossing it if it wasn't. Now we keep the reference. Previously on page load, discover would make 3 calls to `fields_for_wildcard`, now it makes two. It loads all the field with one request and it makes an additional request where it applies the current filter to find relevant fields. Closes elastic#147744
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When there's a data view switch in Discover, this currently leads to 3 requests for the data views fields. Ideally there should be just one.
While this ain't a problem for data views with a small number of fields, it should be optimized for data views with a larger number of fields
The text was updated successfully, but these errors were encountered: