Skip to content

Conversation

@alexwizp
Copy link
Contributor

Summary

This PR fixed problem described in #59044 (comment)

Originally posted by @tylersmalley in #59044

Checklist

Delete any items that are not applicable to this PR.

For maintainers

context: SavedObjectMigrationContext
) => SavedObjectUnsanitizedDoc;
export type SavedObjectMigrationFn<
TInputDoc extends SavedObjectUnsanitizedDoc | SavedObjectSanitizedDoc = SavedObjectUnsanitizedDoc,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to add two generics cause it allow us to avoid a lot of casting in future.

Like e.g. here: src/plugins/dashboard/server/saved_objects/dashboard_migrations.ts
Also using this approach we can guarantee that all Doc's extended from SavedObjectUnsanitizedDoc or SavedObjectSanitizedDoc

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To follow our slack discussion:

This is an alternative of #63943

However on #63943 we choose to only generify the attributes property of SavedObjectUnsanitizedDoc, as we didn't see any (valid) reasons plugin migration functions should be able to superseed/override the root SO type. This could also be dangerous as it may cause developer errors trying to push changes/properties not defined in the schema.

Do you have any usages where you would need to use type override on the whole SavedObjectUnsanitizedDoc type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least in version 7.0.0 references were added. And we should somehow handle it.
Also who knows what will be added in future?

From the other hand if someone wants to add something into doc we have at least 2 options: use JS without typings, just cast object to needed type =) So, validation should be implemented in a different way

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently there's an index signature so anything goes, but we should definitely remove that

Root properties cannot be added by plugins, so if we ever add them in Core, we can update this type at the same time like we recently did for the new namespaces root property.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexwizp could I get your review on #63943? Any argument on why the PR wouldn't answer the need in a better/safer way is welcome.

@alexwizp alexwizp requested a review from VladLasitsa April 23, 2020 10:35
@elastic elastic deleted a comment from kibanamachine Apr 23, 2020
@kibanamachine
Copy link
Contributor

💚 Build Succeeded

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@alexwizp alexwizp marked this pull request as ready for review April 23, 2020 14:32
@alexwizp alexwizp requested review from a team as code owners April 23, 2020 14:32
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch (Team:AppArch)

@alexwizp alexwizp added Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes labels Apr 23, 2020
@alexwizp alexwizp closed this Apr 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes v7.8.0 v8.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants