You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
API generated charts currently doesn't contain information if a XY chart is actually a time based chart or a categorical chart.
We have left this information to be computed/decided at runtime (as it's currently done when you create a chart from the Lens UI).
But information about the current timeField is required:
to filter the chart in the configured time range
to property assign the X axis scale type
This PR fixes this problem (better then the predecessor PR) by hydrating the state at the time of the deserialization.
This can't be done in a later stage (like after the data is received) because we need the timeField information to add the proper DSL filter on top of the ESQL query.
For ESQL folks, I've just extracted the getESQLTimeField into its own file, so it can be easily reused without the need to touch the DataViews as it was initially used.
In our hydration we also need to add the correct meta.type to the column specified at the API level. Because column name and timeField can differ, I've temporarly implemented a function that uses the getQuerySummary to get actual column names associated with possible bucketing aggregations (TBUCKET, BUCKET, DATE_TRUNC) and we use this to match the actual column name described by the API user and associate the proper meta.type.
The previous ensureESQLTimeFieldOnAdHocDataViews was replaced with the hydrateESQLTimeFields.
A set of scout tests are in place to evaluate eventual regressions.
Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
backport:versionBackport to applied version labelsbugFixes for quality problems that affect the customer experienceFeature:Lensrelease_note:skipSkip the PR/issue when compiling release notesTeam:VisualizationsTeam label for Lens, elastic-charts, Graph, legacy editors (TSVB, Visualize, Timelion) t//v9.4.0
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
API generated charts currently doesn't contain information if a XY chart is actually a time based chart or a categorical chart.
We have left this information to be computed/decided at runtime (as it's currently done when you create a chart from the Lens UI).
But information about the current timeField is required:
This PR fixes this problem (better then the predecessor PR) by hydrating the state at the time of the deserialization.
This can't be done in a later stage (like after the data is received) because we need the timeField information to add the proper DSL filter on top of the ESQL query.
For ESQL folks, I've just extracted the getESQLTimeField into its own file, so it can be easily reused without the need to touch the DataViews as it was initially used.
In our hydration we also need to add the correct
meta.typeto the column specified at the API level. Because column name and timeField can differ, I've temporarly implemented a function that uses thegetQuerySummaryto get actual column names associated with possible bucketing aggregations (TBUCKET, BUCKET, DATE_TRUNC) and we use this to match the actual column name described by the API user and associate the proper meta.type.The previous
ensureESQLTimeFieldOnAdHocDataViewswas replaced with thehydrateESQLTimeFields.A set of scout tests are in place to evaluate eventual regressions.
fix #262425
fix #262181