-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Query] Use a minimal index pattern interface for es query #102364
Conversation
…into es-kuery/move-json-utils
|
||
import { IFieldType } from '../../index_patterns'; | ||
|
||
export interface MinimalIndexPattern { |
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.
@mattkime do you have a better name for this?
And what do you think in general?
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 this is fine. Its a bit hacky but it solves the problem without increasing complexity.
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.
Overall I think the approach here makes sense based on our conversation:
IIndexPattern
stays as-is and extends from the base/minimal index pattern- The minimal interface in
es_query
makes it explicit exactly which pieces of index patternses_query
really depends on - It's simple
The main downside is that it feels awkward to have index patterns depend on es-query
, but I don't think that's avoidable without duplicating the types.
import { IFieldType } from '../../index_patterns'; | ||
|
||
export interface MinimalIndexPattern { | ||
fields: IFieldType[]; |
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.
Isn't the dependency on IFieldType[]
going to be a problem too, whenever this gets split out into a package? I'd imagine you'd need to relocate that as well.
FWIW, if it starts to feel weird having all of this stuff crammed in a @kbn/es-query
package, someone had proposed creating something like @kbn/data-types
as a type-specific package just for the data plugin, so that these things could live there instead (and be imported by @kbn/es-query
)
Neither option feels great, just wanted to mention it as something to consider.
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.
Yes, I intend to handle IFieldType
in a followup PR, before moving both into a package
Pinging @elastic/kibana-app-services (Team:AppServices) |
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 work, changes look good!
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @lizozom |
💔 Backport failed
To backport manually run: |
Friendly reminder: Looks like this PR hasn’t been backported yet. |
…02364) * Move JSON utils to utils package * Imports from tests * delete * split package * docs * test * test * imports * minimal index pattern * move some functions out and use miniaml ip in all es-kuery * docs * docs * rename Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> # Conflicts: # docs/development/plugins/data/public/kibana-plugin-plugins-data-public.iindexpattern.md # src/plugins/data/public/public.api.md
…103453) * Move JSON utils to utils package * Imports from tests * delete * split package * docs * test * test * imports * minimal index pattern * move some functions out and use miniaml ip in all es-kuery * docs * docs * rename Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> # Conflicts: # docs/development/plugins/data/public/kibana-plugin-plugins-data-public.iindexpattern.md # src/plugins/data/public/public.api.md
Summary
Part of #51659
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers