Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[8.x] [ES|QL] separate `WHERE` autocomplete routine (#198832)…
… (#199595) # Backport This will backport the following commits from `main` to `8.x`: - [[ES|QL] separate `WHERE` autocomplete routine (#198832)](#198832) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Drew Tate","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-11T08:41:38Z","message":"[ES|QL] separate `WHERE` autocomplete routine (#198832)\n\n## Summary\r\n\r\nPart of https://github.com/elastic/kibana/issues/195418\r\n\r\n**NOTES**\r\n- need to make sure these don't regress\r\n - https://github.com/elastic/kibana/pull/195771\r\n - https://github.com/elastic/kibana/pull/197139\r\n - suggesting variables after binary operator (e.g. `field + <suggest>`\r\n- I've noticed that incomplete null statements such as `is n` are\r\ncorrected in our syntax tree. This sends the autocomplete down a\r\n\"completed operator expression\" route as opposed to an unknown operator\r\nor \"to right of column\" route. So, `... | EVAL foo IS N/` is interpreted\r\nas `... | EVAL foo IS NULL /`.<br><br>It accidentally works (lol)\r\nbecause the logic for `<operator-expression> <suggest>` suggests\r\noperators that accept the return type of the existing operator\r\nexpression as their left-hand argument. Since `foo IS NULL` is of type\r\n`boolean` and `IS NULL` accepts boolean values, it gets included in the\r\nsuggestion list which Monaco then filters by the actual prefix (`IS N`).\r\n🤣 <br><br>([issue](https://github.com/elastic/kibana/issues/199401))\r\n\r\n### Checklist\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Stratoula Kalafateli <[email protected]>","sha":"2466a172af66452bdd939dddc56506faba7ffb7a","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Feature:ES|QL","Team:ESQL","backport:version","v8.17.0"],"title":"[ES|QL] separate `WHERE` autocomplete routine","number":198832,"url":"https://github.com/elastic/kibana/pull/198832","mergeCommit":{"message":"[ES|QL] separate `WHERE` autocomplete routine (#198832)\n\n## Summary\r\n\r\nPart of https://github.com/elastic/kibana/issues/195418\r\n\r\n**NOTES**\r\n- need to make sure these don't regress\r\n - https://github.com/elastic/kibana/pull/195771\r\n - https://github.com/elastic/kibana/pull/197139\r\n - suggesting variables after binary operator (e.g. `field + <suggest>`\r\n- I've noticed that incomplete null statements such as `is n` are\r\ncorrected in our syntax tree. This sends the autocomplete down a\r\n\"completed operator expression\" route as opposed to an unknown operator\r\nor \"to right of column\" route. So, `... | EVAL foo IS N/` is interpreted\r\nas `... | EVAL foo IS NULL /`.<br><br>It accidentally works (lol)\r\nbecause the logic for `<operator-expression> <suggest>` suggests\r\noperators that accept the return type of the existing operator\r\nexpression as their left-hand argument. Since `foo IS NULL` is of type\r\n`boolean` and `IS NULL` accepts boolean values, it gets included in the\r\nsuggestion list which Monaco then filters by the actual prefix (`IS N`).\r\n🤣 <br><br>([issue](https://github.com/elastic/kibana/issues/199401))\r\n\r\n### Checklist\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Stratoula Kalafateli <[email protected]>","sha":"2466a172af66452bdd939dddc56506faba7ffb7a"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/198832","number":198832,"mergeCommit":{"message":"[ES|QL] separate `WHERE` autocomplete routine (#198832)\n\n## Summary\r\n\r\nPart of https://github.com/elastic/kibana/issues/195418\r\n\r\n**NOTES**\r\n- need to make sure these don't regress\r\n - https://github.com/elastic/kibana/pull/195771\r\n - https://github.com/elastic/kibana/pull/197139\r\n - suggesting variables after binary operator (e.g. `field + <suggest>`\r\n- I've noticed that incomplete null statements such as `is n` are\r\ncorrected in our syntax tree. This sends the autocomplete down a\r\n\"completed operator expression\" route as opposed to an unknown operator\r\nor \"to right of column\" route. So, `... | EVAL foo IS N/` is interpreted\r\nas `... | EVAL foo IS NULL /`.<br><br>It accidentally works (lol)\r\nbecause the logic for `<operator-expression> <suggest>` suggests\r\noperators that accept the return type of the existing operator\r\nexpression as their left-hand argument. Since `foo IS NULL` is of type\r\n`boolean` and `IS NULL` accepts boolean values, it gets included in the\r\nsuggestion list which Monaco then filters by the actual prefix (`IS N`).\r\n🤣 <br><br>([issue](https://github.com/elastic/kibana/issues/199401))\r\n\r\n### Checklist\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Stratoula Kalafateli <[email protected]>","sha":"2466a172af66452bdd939dddc56506faba7ffb7a"}},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Drew Tate <[email protected]>
- Loading branch information