Skip to content

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

Merged

Conversation

carlosdelest
Copy link
Member

@carlosdelest carlosdelest commented Nov 14, 2024

Removes snapshot restriction for the match operator (:), allowing it to be used on serverless and regular builds.

Add documentation for the match operator:

Screenshot 2024-11-14 at 15 29 16

image

Adding docs involved some changes, as Match is both a function and an operator:

  • Changing AbstractFunctionTestCase so a new search operators category is added for operators.
  • Add an almost empty MatchOperatorTestCase to make sure the SVG signature is generated for the new operator.

Copy link
Contributor

Documentation preview:

@carlosdelest carlosdelest added >feature auto-backport Automatically create backport pull requests when merged v9.0.0 v8.17.0 labels Nov 14, 2024
@carlosdelest carlosdelest added test-release Trigger CI checks against release build Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch :Search Relevance/Search Catch all for Search Relevance labels Nov 14, 2024
@elasticsearchmachine
Copy link
Collaborator

Hi @carlosdelest, I've created a changelog YAML for you.

@carlosdelest carlosdelest marked this pull request as ready for review November 14, 2024 16:22
@carlosdelest carlosdelest added Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) :Analytics/ES|QL AKA ESQL labels Nov 14, 2024
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-analytical-engine (Team:Analytics)

@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search-relevance (Team:Search Relevance)

Copy link
Member

@fang-xing-esql fang-xing-esql left a 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",
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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
Copy link
Member

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[]
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

@fang-xing-esql fang-xing-esql Nov 19, 2024

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.

Copy link
Member Author

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!

Copy link
Member Author

@carlosdelest carlosdelest Nov 19, 2024

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:

image

[.text-center]
image::esql/functions/signature/match_operator.svg[Embedded,opts=inline]

Supported types:
Copy link
Member

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.

Copy link
Member Author

@carlosdelest carlosdelest Nov 19, 2024

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",
Copy link
Member

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)?

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

@fang-xing-esql fang-xing-esql left a 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",
Copy link
Member

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
@carlosdelest
Copy link
Member Author

@elasticmachine run elasticsearch-ci/bwc-snapshots

@carlosdelest
Copy link
Member Author

@elasticmachine run elasticsearch-ci/8.17.0 / bwc-snapshots

@carlosdelest carlosdelest merged commit ea4b41f into elastic:main Nov 21, 2024
16 of 17 checks passed
carlosdelest added a commit to carlosdelest/elasticsearch that referenced this pull request Nov 21, 2024
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.x
8.18 The branch "8.18" is invalid or doesn't exist

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 116819

@carlosdelest
Copy link
Member Author

💚 All backports created successfully

Status Branch Result
8.17

Questions ?

Please refer to the Backport tool documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/ES|QL AKA ESQL auto-backport Automatically create backport pull requests when merged backport pending >feature :Search Relevance/Search Catch all for Search Relevance Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch test-release Trigger CI checks against release build v8.17.0 v8.18.0 v9.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants