-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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: emit warnings from single-value functions processing multi-values #102417
ESQL: emit warnings from single-value functions processing multi-values #102417
Conversation
This adds Warning headers when scalar singlevalue functions enounter multivalues (and emits a `null`).
This adds warning generation to SingleValueQuery. Two issues with this approch, however: - the source is serialized with the text, the EsqlConfiguration isn't made available. - the translation of queries for Lucene differs from the exec engine, in respect to not(): `must_not` query "contains" the `not` and includes it in its source, while in the exec engine its execution happens in two separate steps (so the warning is added to the predicate the not() negates).
Allow slightly different warnings for Rest and CSV tests.
Currently, this was done on a `"values_count()" != 1`, which is wrong, since it has to differentiate from a 0 count.
Hi @bpintea, I've created a changelog YAML for you. |
Hi @bpintea, I've updated the changelog YAML for you. |
Skip bwc tests on pre 8.12 versions. Also, fix doc test.
Pinging @elastic/es-ql (Team:QL) |
Pinging @elastic/elasticsearch-esql (:Query Languages/ES|QL) |
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 just left a comment about the serial compatibility.
} | ||
|
||
Builder(StreamInput in) throws IOException { | ||
super(in); | ||
this.next = in.readNamedWriteable(QueryBuilder.class); | ||
this.field = in.readString(); | ||
this.stats = new Stats(); | ||
this.source = readSource(in); |
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.
Do we need to bump the transport version for this change?
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.
Actually, where do we serialise 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.
Do we need to bump the transport version for this change?
Good point, we do. I've added a new transport version.
Actually, where do we serialise this?
The doWriteTo()
method below updates the serialisation based on the transport version.
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.
Great! I only have minor remarks except for what Chris already pointed out.
Like Chris, I think we'll need to bump transport version since we're now sending the source along with single value queries.
Do we need to account for this in other ways as well? I guess if we have a transport connection to 8.11 nodes, we could just not send the source to avoid breaking bwc?
x-pack/plugin/ql/test-fixtures/src/main/java/org/elasticsearch/xpack/ql/CsvSpecReader.java
Show resolved
Hide resolved
.../plugin/esql/src/main/java/org/elasticsearch/xpack/esql/querydsl/query/SingleValueQuery.java
Show resolved
Hide resolved
...ql/src/test/java/org/elasticsearch/xpack/esql/optimizer/LocalPhysicalPlanOptimizerTests.java
Show resolved
Hide resolved
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
@elasticsearchmachine run elasticsearch-ci/docs |
This is a big usability improvement - let's get this in for 8.12. |
@elasticsearchmachine run elasticsearch-ci/part-3 elasticsearch-ci |
I've merged this as-is, since it bumps the
We could, yes. The only two concerns I'd have is that:
I'll update the message. |
When encountering a multi-value, a single-value function (i.e. all non-
mv_xxx()
) returns anull
. This behaviour is opaque to the user. This PR adds the functionality for these functions to emit aWarning
header, so the user is informed about the cause for thenull
s.Within testing, there are some differences between the emulated CSV-based tests (
TestPhysical*
) and the REST CSV-tests and thus the exact messages in the warnings:not <predicate>
, can be translated to amust_not
query, that will include thenot
in theSource
. But outside of Lucene, the execution would consider the predicate first, then the negation. So when the predicate contains a SV function, only this part'sSource
will show up in the warning.SingleValueQuery
. This emits now warnings when encountering MVs (and returning no match). However, this only happens once the query that it wraps returns something itself. Comparatively, theTestPhysical*
filters will issue a warning for every encountered MV (irrespective of sigle values within the MV matching or not).To differentiate between the slightly differing values of the warnings, one can now append the
#[Emulated:
prefix to a warning, followed by the value of the warning for the emulated checks, then a corresponding]
.Example:
warning:Line 1:24: evaluation of [not(salary_change < 1)] failed, treating result as null. Only first 20 failures recorded.#[Emulated:Line 1:28: evaluation of [salary_change < 1] failed, treating result as null. Only first 20 failures recorded.]
Closes #98743.