[ES|QL] AST pretty-printing #182257
Assignees
Labels
DX
Issues related to Developer Experience
enhancement
New value added to drive a business result
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
enhancement
|
Pinging @elastic/kibana-esql (Team:ESQL) |
stratoula
added
the
impact:medium
8 tasks
vadimkibana
changed the title
|
Depends on #189259 |
|
Depends on #182393 (comment) |
|
Optionally depends on #182393 (comment) and #182393 (comment) |
|
Blocked by #189491 |
|
Blocked by #189913 |
2 tasks
vadimkibana
added a commit
that referenced
this issue
Aug 6, 2024
## Summary Partially addresses #182257 Add a helper function, which given an ES|QL AST formats it to a one-line string. ### Checklist Delete any items that are not applicable to this PR. - [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 ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
2 tasks
vadimkibana
added a commit
that referenced
this issue
Aug 20, 2024
## Summary Partially addresses #182257 - Improves the basic "one-line" printer `BasicPrettyPrinter`, notable changes: - It is now possible better specify if query keywords should be uppercased - Better formatting columns names, adds backquotes when escaping needed: `` `name👍` `` - Wraps cast expressions into brackets, where needed: `(1 + 2)::string` instead of `1 + 2::string` - Adds initial implementations of the more complex `WrappingPrettyPrinter`. - "Initial implementation" because it probably covers 80-90% of the cases, some follow up will be needed. - The `WrappingPrettyPrinter` formats the query like `Prettier`, it tries to format AST nodes horizontally as lists, but based on various conditions breaks the lines and indents them. #### Cases handled by the `WrappingPrettyPrinter` Below are examples of some of the cases handled by the `WrappingPrettyPrinter`. (See test files for many more cases.) ##### Short queries Queries with less than 4 commands and if they do not require wrapping are formatted to a single line. Source: ``` FROM index | WHERE a == 123 ``` Result: ``` FROM index | WHERE a == 123 ``` ##### Argument wrapping Command arguments are wrapped (at wrapping threshold, defaults to 80). Source: ``` FROM index, another_index, yet_another_index, on-more-index, last_index, very_last_index, ok_this_is_the_last_index ``` Result: ``` FROM index, another_index, yet_another_index, on-more-index, last_index, very_last_index, ok_this_is_the_last_index ``` ##### Argument breaking Command argument combinations which result into a single argument occupying a whole line (due to that argument being long, or because the surrounding argument combination results into such a case), except the last argument, results into the argument list being broken by line. Source: ``` FROM xxxxxxxxxx, yyyyyyyyyyy, zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, // <------------ this one bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, ccccccc, ggggggggg ``` Result: ``` FROM xxxxxxxxxx, yyyyyyyyyyy, zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, ccccccc, ggggggggg ``` ##### Binary expression chain vertical flattening Binary expressions of the same precedence are vertically flattened, if wrapping is required. Same as it is done by `Prettier`, where there is an indentation after the first line to allow for different precedence expressions. ###### All expressions have the same precedence Source: ``` FROM index | STATS super_function_name(11111111111111.111 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111)) ``` Result: ``` FROM index | STATS SUPER_FUNCTION_NAME( 11111111111111.111 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111) ``` ###### Expressions with `additive` and `multiplicative` precedence mixed Source: ``` FROM index | STATS super_function_name(11111111111111.111 + 3333333333333.3333 * 3333333333333.3333 * 3333333333333.3333 * 3333333333333.3333 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111)) ``` Result: ``` FROM index | STATS SUPER_FUNCTION_NAME( 11111111111111.111 + 3333333333333.3335 * 3333333333333.3335 * 3333333333333.3335 * 3333333333333.3335 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111 + 11111111111111.111) ``` ### Checklist Delete any items that are not applicable to this PR. - [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 ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
2 tasks
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are use cases for making programmatic edits to an ES|QL query. For example, adding or changing a
whereclause when a user filters by a field (ref).We have code to parse an ES|QL string to an AST (a reader), but no code for the inverse (a generator).
This leaves us no choice but to use string manipulation.
Instead, we should provide a generator so that edits can be made to the AST and then serialized into a new query. This is a more robust and less error-prone method of manipulating queries.
The text was updated successfully, but these errors were encountered: