[ES|QL] auto bucket and constant-only parameter improvements#180509
[ES|QL] auto bucket and constant-only parameter improvements#180509drewdaemon merged 11 commits intoelastic:mainfrom
Conversation
…ket-should-accept-date
130eff6 to
51b1635
Compare
|
/ci |
|
Pinging @elastic/kibana-esql (Team:ESQL) |
|
One open question: how do we want the highlighting and messaging to work in the case of a nested non-constant? e.g. given only
Questions
WDYT @stratoula ? |
|
@drewdaemon thanx, I played with it and seems really nice
Yes the entire argument, otherwise is weird
I suggest something simple as this argument for |
packages/kbn-esql-validation-autocomplete/src/autocomplete/autocomplete.ts
Outdated
Show resolved
Hide resolved
| name: string; | ||
| description: string; | ||
| args?: Array<{ name: string; type: string; value: string; literalOnly?: boolean }>; | ||
| args?: Array<{ name: string; type: string; value: string; constantOnly?: boolean }>; |
There was a problem hiding this comment.
why this renaming?
In ES|QL there's the concept of literal but not of constant (which is an Monaco concept).
There was a problem hiding this comment.
Actually, I was hoping this change would align us closer with ES since they use "constant" in their error messages. Wasn't aware of the Monaco thing.
[esql] > Unexpected error from Elasticsearch: verification_exception - Found 1 problem
line 1:51: second argument of [bucket(bytes, bytes, 30, 20)] must be a constant, received [bytes]
WDYT?
|
@stratoula I've condensed the error messages and highlighting so they make more sense.
To your other point
I think this could be a nice improvement. Right now, all the error messages follow a similar pattern (see Also, maybe @dej611 has some input on the thinking behind the way the error messages are currently formatted? |
In general if there's an existing ES error message for something I think we should adopt their message to avoid confusion for the user. I see the current message is diverging from the current ES one who puts the entire vs The messaging copy used for the non-ES messages are using the same baseline as the other ES ones. As for the highlight problem, I have a dilemma there as in terms of visual feedback I think it's better, but the error message provided does not provide the right information to the user. Perhaps nested vs nested scenarios ought to have two distinct messages? I think this should also be discussed with the ES team as well to align. As for now, I think it is ok to unblock on the full function highlight + error message. |
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Page load bundle
History
To update your PR or re-run it, just comment with: |
|
@drewdaemon I don't think you can backport, in 8.13 it was If you added this for the FF I think if you merge it today, we are fine! |
stratoula
left a comment
There was a problem hiding this comment.
I am fine with the messaging and the highlight, it is much more clear than before. I can see the difference with ES that Marco mentioned, we could align but honestly I find our message more clear so I am fine on proceeding with this small difference. 👍
|
@stratoula the backport was to get it into 8.14. However, I'm glad you mentioned this because it looks like it hasn't been branched yet. I'm not worried about ff because I consider this a set of bug fixes 👍 |


Summary
Close #180061
Key fixes
auto_bucketbucketas of ESQL: Rename AUTO_BUCKET to just BUCKET elasticsearch#107197auto-bucket's 2nd, 3rd, and 4th parameters, all of which must be constantsauto_bucket(@timestamp, abs(length(bytes)), "", ""))Outstanding issues
Validator sees the problem
Validator doesn't see the problem
Checklist