[ES|QL] generate function definitions from ES metadata #179634
Assignees
Labels
enhancement
New value added to drive a business result
Feature:ES|QL
ES|QL related features in Kibana
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
Team:ESQL
ES|QL related features in Kibana
Comments
drewdaemon
added
Feature:ES|QL
|
Pinging @elastic/kibana-esql (Team:ESQL) |
5 tasks
stratoula
added
enhancement
2 tasks
|
PR for eval function definitions on the Elasticsearch side elastic/elasticsearch#106782 |
This was referenced Apr 9, 2024
|
A note on interpreting the ES function definitions
|
This was referenced Apr 15, 2024
drewdaemon
added a commit
that referenced
this issue
May 9, 2024
## Summary Preparation for #179634 --------- Co-authored-by: Kibana Machine <[email protected]>
drewdaemon
added a commit
that referenced
this issue
May 24, 2024
…79584) ## Summary Resolve #179634 This PR introduces a script to gather metadata from Elasticsearch and build the function definitions for Kibana's client-side validation. To run the script: `cd packages/kbn-esql-validation-autocomplete && yarn makedefs path/to/elasticsearch/repo` ## Current limitations ### Things we can't (yet) gather from ES #### Things that are currently being filled in on the Kibana side but would be missing if we had to rely completely on ES - function aliases (e.g. `to_str`) - operators and aggs (issues for Elasticsearch elastic/elasticsearch#107219 and elastic/elasticsearch#107220) - Kibana AST parameter settings - `constantOnly` — whether a parameter can be a non-literal or not (`percentile`, `auto_bucket`) - `constantOptions`/`constantSuggestions` — specific information about which constants are accepted or suggested for particular parameters. - `supportsWildcard` — whether a parameter can contain `*` (only `count` at the moment) - `noNestingFunctions` — whether a parameter can contain nested functions (used for all agg functions) - Kibana date constant types - `chrono_literal` - `time_literal` ### Other considerations - Asciidoc links need to be scrubbed (e.g. `Function {wikipedia}/foo/bar[arccosine] returns blah blah`) - As of elastic/elasticsearch#106454 some descriptions reference outdated parameter names and some parameter names are questionable: <img width="600" alt="Screenshot 2024-03-28 at 1 07 16 PM" src="https://github.com/elastic/kibana/assets/315764/3b9ab457-e9fd-4c5f-afb2-23ae769bb44a"> _parameter `n` is now called `number`, but the description still calls it `n`... also, is `number` really the best name for the variable?_ ### Checklist - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Stratoula Kalafateli <[email protected]> Co-authored-by: kibanamachine <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature:
We currently maintain our own function definitions (here, here, and here) and rely on manual updates to keep them in sync with changes in Elasticsearch.
Instead, we should generate these definitions automatically from whatever information we can glean from Elasticsearch so that there's (mostly) one source of truth.
Elasticsearch has a
meta functionscommand which returns a list of available functions (not including operators). It has several limitations, but we can use it as a starting point.This routine should be run on a regular schedule in CI.
The text was updated successfully, but these errors were encountered: