[Lens][as-code] fix metric trendlines#254093
Conversation
drewdaemon
added
release_note:skip
|
@elasticmachine merge upstream |
andrimal
left a comment
andrimal
left a comment
There was a problem hiding this comment.
Tested locally and works great! 🚀
Left only one comment.
| operation: 'date_histogram', | ||
| include_empty_rows: true, | ||
| suggested_interval: 'auto', | ||
| use_original_time_range: true, |
There was a problem hiding this comment.
I noticed that currently without the api transformations, when setting a trendline from UI the date histograms are created without ignoreTimeRange.
I don't think this creates a different functionality in this case, but may be for parity we should also omit it? What do you think?
There was a problem hiding this comment.
I think we should have parity, thanks
| }), | ||
| schema.object({ | ||
| type: schema.literal('trend'), | ||
| time_field: schema.string({ meta: { description: 'Time field for trend chart' } }), |
There was a problem hiding this comment.
The approach is simple and effective, but I have doubts this can correctly scale (it doesn't consider for example how we want to integrate ESQL in the near future).
The concept of field is limited to DSL and doesn't play with the current ESQL setup we use.
Since this is actually configured behind the scene in Lens datasource as a date_hisogram + same metric layer configuration and is done based on the current data_view configuration, do you think we can instead of doing that at the transformation side, we can "hydrate" the datasources at the rendering/runtime side?
In this way we don't need anything special, we just need to consider that the background_chart is of type trend and we inject that datasource cnofiguration.
When we are going to implement ESQL + the possibility to configure that trendline in a better way (different agg, dfferent histogram etc) we can add a parameter like the operation that allows us to construct and provide a better definition.
WDYT?
There was a problem hiding this comment.
As you suggested offline, I'll try out using the full date histogram schema instead of the short-hand field.
"background_chart": {
"type": "trend",
"x": bucketDateHistogramOperationSchema
}
This is a schema we will have to support in ES|QL anyways, so we aren't making things harder in the future.
There was a problem hiding this comment.
Okay, I tried this out, but I'm not sure it's an improvement. It does re-use something we already have to support, but it is much more verbose and still mentions the word, "field."
WDYT
There was a problem hiding this comment.
let's just add the operation + field that is the way we determine the type of operation.
Everything else can be hidden (we don't have a real contract on how we handle the trendline behind the scene so is fine to avoid that)
|
There's a desire to plan for trendline schema consistency across the Lens classic visualizations (DSL) and ES|QL-based visualizations (which will support trendlines at some point). Therefore, this PR is blocked on further direction from the team. |
|
@drewdaemon @andrimal I've tried the runtime hydration mechanism and seems to work fine Please double check this PR #258104 |
|
closing in favor of #258104 ! |
4 participants
Summary
Fix #251620
Screen.Recording.2026-02-19.at.3.21.14.PM.mov
Checklist