Skip to content
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.

Sign up for GitHub

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

Update ZDT update limitation to only bulkUpdate #167200

Merged
merged 2 commits into from
Sep 26, 2023
Merged

Update ZDT update limitation to only bulkUpdate #167200

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
60d6238
Remove ZDT update limitation now that it's been solved
rudolf Sep 25, 2023
6b777a6
Add back update limitation but this time for bulkUpdate only
rudolf Sep 25, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 13 additions & 5 deletions packages/core/saved-objects/core-saved-objects-server/docs/model_versions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -893,9 +893,11 @@ to the `fields` option **were already present in the prior model version**. Othe
during upgrades, where newly introduced or backfilled fields may not necessarily appear in the documents returned
from the `search` API when the option is used.

### Using `update` with dynamically backfilled fields
### Using `bulkUpdate` with dynamically backfilled fields

The savedObjects `update` API is effectively a partial update (using Elasticsearch's `_update` under the hood),
(Note: this same limitation used to exist for the `update` method but has been [fixed](https://github.com/elastic/kibana/issues/165434). So while they're similar this limitation is only relevant for the `bulkUpdate` method)

The savedObjects `bulkUpdate` API is effectively a partial update (using Elasticsearch's `_update` under the hood),
allowing API consumers to only specify the subset of fields they want to update to new values, without having to
provide the full list of attributes (the unchanged ones). We're also not changing the `version` of the document
during updates, even when the instance performing the operation doesn't know about the current model version
Expand Down Expand Up @@ -935,8 +937,14 @@ const newDocAttributes = {
Which could occur either while being still in the cohabitation period, or in case of rollback:

```ts
savedObjectClient.update('type', 'id', {
index: 11,
savedObjectClient.bulkUpdate({
objects: [{
type: 'type',
id: 'id',
attributes: {
index: 11
}
}]
});
```

Expand All @@ -949,7 +957,7 @@ We will then be in a situation where our data is **inconsistent**, as the value
}
```

The long term solution for that is implementing [backward-compatible updates](https://github.com/elastic/kibana/issues/152807), however
The long term solution for that is implementing [backward-compatible updates](https://github.com/elastic/kibana/issues/165434), however
this won't be done for the MVP, so the workaround for now is to avoid situations where this edge case can occur.

It can be avoided by either:
Expand Down