-
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
[SOR] Remove fields
API
#153447
[SOR] Remove fields
API
#153447
Conversation
3c087d4
to
72b8f87
Compare
@@ -43,7 +43,6 @@ async function checkOrigin( | |||
rootSearchFields: ['_id', 'originId'], | |||
page: 1, | |||
perPage: 1, // we only need one result for now | |||
fields: ['title'], // we don't actually need the object's title, we just specify one field so we don't fetch *all* fields |
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.
We may want to add an option for retrieving the root fields only
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.
Perhaps an option to return just "meta" fields like ID, createdAt, updatedAt?
if (req.query.fields) { | ||
usageCounter?.incrementCounter({ | ||
counterName: `alertingFieldsUsage`, | ||
counterType: 'alertingFieldsUsage', | ||
incrementBy: 1, | ||
}); | ||
} |
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 checked our telemetry, and this is not used in 8.x versions.
if (query.fields) { | ||
usageCounter?.incrementCounter({ | ||
counterName: `legacyAlertingFieldsUsage`, | ||
counterType: 'alertingFieldsUsage', | ||
incrementBy: 1, | ||
}); | ||
} |
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.
Telemetry tells us that 7.16 was the last version this was used.
72b8f87
to
796ccf1
Compare
Pinging @elastic/kibana-core (Team:Core) |
@@ -57,7 +57,6 @@ export async function migrateLegacyAPMIndicesToSpaceAware({ | |||
type: 'space', | |||
page: 1, | |||
perPage: 10_000, // max number of spaces as of 8.2 | |||
fields: ['name'], // to avoid fetching *all* fields |
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.
This fee;s like a pretty big change in terms of performance. Is the suggestion to avoid using SOs for documents with many fields (or fields containing big blobs of data) where only few or lightweight fields are needed in the majories of queries?
We are already using custom (system) indices for certain features (agent configs, custom links) where SOs were deemed a bad fit. This seems like yet another reason to avoid SOs.
Edit: Perhaps worth adding to #80912
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'm also concerned about the performance impact of this change. Synthetics is using saved objects for monitor configurations, and those documents can quite heavy. This is especially true for our project monitor feature where the script of the monitor is base64 encoded zip file of the script, plus any imports including node_modules.
If the saved object client was only called on the server side, and the fields set to the request were always hardcoded, not part of the HTTP API contract, and transformed to match the HTTP contract before returning the data, would that be enough to satisfy the requirements for the HTTP versioning initiative? This is close to how we use fields currently and matches our original expectations of the work needed to meet the requirements.
Pinging @elastic/fleet (Team:Fleet) |
Pinging @elastic/apm-ui (Team:APM) |
Pinging @elastic/uptime (Team:uptime) |
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.
Changes in SO API integration tests LGTM.
💚 Build Succeeded
Metrics [docs]Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @afharo |
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.
Infra UI changes LGTM.
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 read through core-only changes and they look good to me. Great job @afharo !
I am glad to see we are reducing API surface area, but I do wonder whether removal of this option has any performance impact on either server or browser? I don't have data to think there is an issue but I can imagine that if we are now returning an array of really large objects there could be an issue.
Otherwise, approving to unblock progress!
@@ -43,7 +43,6 @@ async function checkOrigin( | |||
rootSearchFields: ['_id', 'originId'], | |||
page: 1, | |||
perPage: 1, // we only need one result for now | |||
fields: ['title'], // we don't actually need the object's title, we just specify one field so we don't fetch *all* fields |
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.
Perhaps an option to return just "meta" fields like ID, createdAt, updatedAt?
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.
Fleet change LGTM, though I have the same concern related to performance. Is there an alternative we could use to avoid returning all fields?
@sqren @juliaElastic @shahzad31, the main reason for this change is that, in the scope of ZDT migrations, Kibana might run when migrations have not been applied yet. In that phase, we might apply the migrations at runtime. Fetching a partial document from ES before being migrated won't ensure the requested Having said that, we are looking at an alternative option: during the transition, internally fetch the entire document from ES, apply the migration, and We might need some help from your end, though: given we are using these filters for performance purposes, we'd like to know the performance gain. It'd be great if we had some scalability tests for the tasks you want to optimize. |
Summary
Resolves #152808
Checklist
Risk Matrix
For maintainers