-
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
[Saved objects] Prepare SO management for versionable types #149495
[Saved objects] Prepare SO management for versionable types #149495
Conversation
… HTTP API endpoint interfaces
@TinaHeiligers @rudolf @pgayvallet I've tried to incorporate feedback. Let me know what you think of the current iteration:
|
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.
The recent changes look good to me!
* Saved Object Management metadata associated with a saved object. See | ||
* {@link SavedObjectWithMetadata}. | ||
*/ | ||
export interface SavedObjectMetadata { |
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.
Are the types that don't have the V1
suffix not expected to change at all? I'd expect to see all the types and interfaces declared in this file to only be the ones that change.
Shared types/interfaces that we can guarantee will never change could live elsewhere, for example, in the main types
file.
Keeping the versioned-types file as small as possible helps us monitor changes over time.
} | ||
); | ||
objects: v1.BulkDeleteBodyHTTP | ||
): Promise<v1.BulkDeleteResponseHTTP> { |
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.
Should we indicate these are for internal purposes only?
/* @internal */
export function bulkDeleteObjects(...
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.
It's so hard to get it right the first time, thanks for keeping up!
For now, I'm ok with the proposed changes.
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
@TinaHeiligers @rudolf @pgayvallet thanks for all the input so far! @pgayvallet and I spoke about the current approach: For now, lets go with the general recommendation that you should version a collection/namespace of types, instead of individual types. Ultimately, plugins can version domain types however they choose, but the assumption is that it will be common that a set of interfaces change together. In the case of SO management plugin we have a few domains AFAICT:
We could group these in individual domains that are versioned independently (where if one type changes, naturally others will change). So we could have domain: However, the current API surface area is quite small and I'm not sure this will yield value for that level of effort. So everything just lives under an unqualified See the |
We can capture details not represented here when working on #149929 |
## Summary This PR addresses 4 TODOs identified in #149495. We address these TODOs by taking a closer look at actual use of flagged fields in public code: 1. `FindQueryHTTP['namespaceType']`: Probably OK to directly expose this as it seems highly unlikely this value will change soon... We should also be able to version it since it is a well known set. 2. `FindQueryHTTP['search']`: looks like it is allowing users to enter _any_ search value against SO attribs. However, this functionality is constrained because it only takes a search term and runs it against a server-side determined search field. The risk is that consumers of the server-side functionality do not keep their default search field up-to-date. 3. `FindQueryHTTP['fields']`: Our UI only ever passes in `id` here. We should consider a follow up PR to add some counter telemetry to track usage of this option and consider removing it entirely. 4. `FindQueryHTTP['sortField']`: Lock this down to a well known set of values (probably the riskiest change here). --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary Adds a dev docs guide for the core-approved versioning strategy. This strategy is subject to some iteration but is based on the work we did for the Saved Objects Management plugin in #149495. Closes #149929 ## How to test 1. Run `./scripts/dev_docs.sh` 2. Navigate to "Versioning interfaces" in the side nav menu --------- Co-authored-by: Luke Elmers <lukeelmers@gmail.com>
## Summary Adds a dev docs guide for the core-approved versioning strategy. This strategy is subject to some iteration but is based on the work we did for the Saved Objects Management plugin in elastic#149495. Closes elastic#149929 ## How to test 1. Run `./scripts/dev_docs.sh` 2. Navigate to "Versioning interfaces" in the side nav menu --------- Co-authored-by: Luke Elmers <lukeelmers@gmail.com>
Summary
Part of preparing HTTP APIs and associated interfaces for versioning:
common
SavedObject
type from publicRelated #149098
Fixes #149495