-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Lens] Support index pattern runtime fields in existence and field stats API #90600
Conversation
@elasticmachine merge upstream |
@elasticmachine merge upstream |
Pinging @elastic/kibana-app (Team:KibanaApp) |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
track_total_hits: true, | ||
body: { | ||
query, | ||
aggs, | ||
runtime_mappings: | ||
!field.isMapped && field.runtimeField ? { [fieldName]: field.runtimeField } : {}, |
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 am not 100% sure if this is the "correct" behavior for runtime fields shadowing mapped fields. @mattkime Will runtime fields shadowing mapped fields report as isMapped: true
and runtimeField: true
(that was my understanding so far). If it's the case we should not check on isMapped
here and always write the script if runtimeField === true
.
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.
Good point Tim, fixed 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.
Tim's understanding is correct.
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.
Tested with Chrome and Safari, but I am a bit lost on what the expected result of this PR.
The only difference I noticed with master
is this +
button feature enabled:
The error notification is still showing up and the data popover is still empty (or in general it does not show any extra information).
Edit: also with this PR everytime I open the data popover I see this error on the server (before there was none):
server error [12:49:52.958] Error: Internal Server Error
at HapiResponseAdapter.toError (~/kibana/src/core/server/http/router/response_adapter.ts:122:19)
at HapiResponseAdapter.toHapiResponse (~/kibana/src/core/server/http/router/response_adapter.ts:72:19)
at HapiResponseAdapter.handle (~/kibana/src/core/server/http/router/response_adapter.ts:67:17)
at Router.handle (~/kibana/src/core/server/http/router/router.ts:273:34)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at handler (~/kibana/src/core/server/http/router/router.ts:227:11)
at exports.Manager.execute (~/kibana/node_modules/@hapi/hapi/lib/toolkit.js:60:28)
at Object.internals.handler (~/kibana/node_modules/@hapi/hapi/lib/handler.js:46:20)
at exports.execute (~/kibana/node_modules/@hapi/hapi/lib/handler.js:31:20)
at Request._lifecycle (~/kibana/node_modules/@hapi/hapi/lib/request.js:370:32)
at Request._execute (~/kibana/node_modules/@hapi/hapi/lib/request.js:279:9)
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.
Tested in Chrome, the described test case works as expected. Code looks good to me.
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.
These changes make sense and I tested that they work as expected. It seems like there are some missing pieces that are pretty important:
- No functional test
- There is still no UI for managing these, I assume this is coming soon?
@@ -32,17 +32,14 @@ export default ({ getService }: FtrProviderContext) => { | |||
describe('field distribution', () => { |
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 would appreciate a functional test for an index pattern runtime field, seems like it's missing
@elasticmachine merge upstream |
I'm going to postpone merging this PR until after feature freeze to reduce some risk as index pattern runtime fields won't land in 7.12 anyway. |
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
1 similar comment
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
I'm getting there, kibana machine, I'm trying really hard |
…eld stats API (#90600) (#91872) * [Lens] Support index pattern runtime fields in existence and field stats API (#90600) * fix fixture Co-authored-by: Kibana Machine <[email protected]>
Fixes #90175 This PR reads the index pattern and includes index pattern level runtime fields for the requests of field existence and field stats API
To test:
what_a_fielding
should work correctlyTo simplify a little, this PR also changes the field stats API to include the index pattern id and field name instead of the index pattern title and field definition (as these things can be looked up on the server side). I don't have a strong opinion on this, but it looks like a simpler API to me (which probably wasn't possible in earlier versions because index patterns were not available on the server)