[ES|QL] Enabling the timepicker for indices without the @timestamp field#184361
[ES|QL] Enabling the timepicker for indices without the @timestamp field#184361stratoula merged 63 commits intoelastic:mainfrom
Conversation
| dataView.isTimeBased() && | ||
| query && | ||
| isOfAggregateQueryType(query) && | ||
| getAggregateQueryMode(query) === 'esql' && |
There was a problem hiding this comment.
ℹ️ Irrelevant with this PR, I just removed it as is not needed anymore (we removed SQL)
|
/ci |
|
Looks interesting! I'm wondering how else we might use it... 🤔 In this PR, am I understanding correctly that |
|
@ryankeairns yes exactly, these are system parameters, defined by us. Eventually being part of our autocomplete too.
They should and I think a nice idea to do so is to combine controls with named parameters. Not part of this PR though, we need to think about it and it needs design input my friend |
Great, thanks for clarifying. Regarding system parameters, might we consider a unique prefix/naming convention? Otherwise, we could run into more complexity in validation, later, where we have to block/error on the use of system param names when users attempt to add them to their query, unknowingly. Something like... |
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
…esql/_esql_view.ts Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
…utils/get_esql_data_view.test.ts Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
…utils/get_esql_data_view.test.ts Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
…utils/get_esql_data_view.test.ts Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
…utils/get_esql_data_view.test.ts Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
No, I didn't mean this. Let's say that a sample ecommerce data has Also this way we would teach how to use these named params. |
|
@jughosta I see now 👍 This is not a bad idea, I will add it as a discussion point for our next ESQL sync to see how the other feel about it! |
| const timeFilter = getTime(undefined, timeRange, { | ||
| fieldName: this._descriptor.dateField, | ||
| }); | ||
| const namedParams = getEarliestLatestParams(this._descriptor.esql, timeRange); |
There was a problem hiding this comment.
It looks like the problem I flagged is happening because getEarliestLatestParams is in if (requestMeta.applyGlobalTime) block. Instead, getEarliestLatestParams should be moved outside of this if statement so params are always added.
I would assume users would disable "Apply global time range" when using ?earliest and ?latest since you would not want both.
There was a problem hiding this comment.
Great find Nathan! I had to move the timeRange computation outside too. I hope it makes sense 04a243f
|
You will also need to update Without these changes, then changes to the global time selector are not applied to the layer. |
done here bd30542 |
|
/ci |
nreese
left a comment
There was a problem hiding this comment.
kibana-gis changes LGTM
code review, tested in chrome.
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
async chunk count
History
|

Summary
Based on elastic/elasticsearch#108421
Closes #180805
It allows the users to add an
?earliestand?latestvariable in the ES|QL editor.When we are detecting this variable, we are also sending the values to ES.
Usage in bucket
This enables 2 very important features:
@timestampfieldFor reviewers
getESQLAdHocDataviewgetESQLResultsfrom the esql-utils. I will create an issue for the ML team.Follow ups
Flaky test runner
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6521