-
Notifications
You must be signed in to change notification settings - Fork 25.2k
ESQL - match operator included in non-snapshot builds #116819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESQL - match operator included in non-snapshot builds #116819
Conversation
Documentation preview: |
Hi @carlosdelest, I've created a changelog YAML for you. |
Pinging @elastic/es-analytical-engine (Team:Analytics) |
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @carlosdelest, I added some comments to the generated docs.
@@ -151,7 +151,7 @@ | |||
], | |||
"examples" : [ | |||
"FROM employees\n| STATS COUNT(height)", | |||
"FROM employees \n| STATS count = COUNT(*) BY languages \n| SORT languages DESC", | |||
"FROM employees\n| STATS count = COUNT(*) BY languages\n| SORT languages DESC", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be a leftover of a prior PR, not relevant to this PR. Just want to mention it in case it is included by mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was re-generated by tests - happy not to include it, but shouldn't we use the opportunity to keep these generated files up to date?
Same happened with qstr, where examples were generated as uppercase instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think it is good to keep the generated docs up to date, it makes main clean.
[%header.monospaced.styled,format=dsv,separator=|] | ||
|=== | ||
field | query | result | ||
keyword | keyword | boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The types listed here seem to be different from the match function's types - docs/reference/esql/functions/types/match.asciidoc
, should we make them consistent?
|
||
Supported types: | ||
|
||
include::types/match.asciidoc[] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be nice to include an example of the match operator here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for doing that it would be needed to add a new MatchOperator
class with the corresponding @FunctionInfo
annotation that contains the examples, so they are auto-generated and can be linked.
We could create that class just for doc purposes and avoid instantiating it, or make it subclass Match
- it could even be used to represent the operator instead of using Match
for both the function and the operator.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The search.asciidoc
is not a generated file, we can just add an example of match operator manually without adding a new class. in.asciidoc
has an example of including a csvtest there. Perhaps just pick one example with tag from match-operator.csv-spec
and add it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I didn't know we could add CSV tests directly without generating the examples via tests. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added an example in 22f4388, now search operators looks like:
[.text-center] | ||
image::esql/functions/signature/match_operator.svg[Embedded,opts=inline] | ||
|
||
Supported types: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a duplicated line in the doc, the link below also has supported types
before the table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the catch! Fixed in af0b035
"params" : [ | ||
{ | ||
"name" : "field", | ||
"type" : "keyword", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docs/reference/esql/functions/kibana/definition/match.json
has both keyword
and text
types, should we make them consistent(needs additional tests on text
type for the operator)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right - I added the missing field types in 68907ff.
needs additional tests on text type for the operator
I think text
type is already covered in CSV tests? Are there other tests you would expect to check this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean to add text
type in the MatchOperatorTests
so that the text
type can be included in the docs automatically, which you already did in the latest commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for completeness, in docs/reference/esql/functions/kibana/definition/match.json
, we have 4 combinations:
keyword, keyword
keyword, text
text, keyword
text, text
docs/reference/esql/functions/kibana/definition/match_operator.json
has 2 combinations:
keyword, keyword
text, text
Adding two additional tests for the other two combinations in MatchOperatorTests
should be able to make the types of :
the same as match
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it - adding them in cdf896c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you @carlosdelest, as far as CI is happy ! I added a minor comment on the types for kibana.
"params" : [ | ||
{ | ||
"name" : "field", | ||
"type" : "keyword", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for completeness, in docs/reference/esql/functions/kibana/definition/match.json
, we have 4 combinations:
keyword, keyword
keyword, text
text, keyword
text, text
docs/reference/esql/functions/kibana/definition/match_operator.json
has 2 combinations:
keyword, keyword
text, text
Adding two additional tests for the other two combinations in MatchOperatorTests
should be able to make the types of :
the same as match
function.
# Conflicts: # x-pack/plugin/esql/src/main/antlr/EsqlBaseLexer.tokens # x-pack/plugin/esql/src/main/antlr/EsqlBaseParser.tokens # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/parser/EsqlBaseLexer.interp # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/parser/EsqlBaseLexer.java # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/parser/EsqlBaseParser.interp # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/parser/EsqlBaseParser.java
@elasticmachine run elasticsearch-ci/bwc-snapshots |
@elasticmachine run elasticsearch-ci/8.17.0 / bwc-snapshots |
💔 Backport failed
You can use sqren/backport to manually backport by running |
(cherry picked from commit ea4b41f)
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
Removes snapshot restriction for the match operator (:), allowing it to be used on serverless and regular builds.
Add documentation for the match operator:
Adding docs involved some changes, as Match is both a function and an operator:
AbstractFunctionTestCase
so a new search operators category is added for operators.MatchOperatorTestCase
to make sure the SVG signature is generated for the new operator.