-
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
[Lens] Migration from 7.7 #62879
[Lens] Migration from 7.7 #62879
Conversation
Pinging @elastic/kibana-app (Team:KibanaApp) |
*/ | ||
|
||
import { migrations, RawLensSavedXYObject770 } from './migrations'; | ||
import { SavedObjectUnsanitizedDoc } from 'src/core/server'; |
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 line is the only difference from 7.7 in the tests
@@ -22,6 +23,7 @@ export function setupSavedObjects(core: CoreSetup) { | |||
uiCapabilitiesPath: 'visualize.show', | |||
}), | |||
}, | |||
migrations, |
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 line is slightly different from 7.7 because migrations are now registered to specific types
*/ | ||
|
||
import { cloneDeep } from 'lodash'; | ||
import { SavedObjectUnsanitizedDoc } from 'src/core/server'; |
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 import is slightly different as the migrations are now importing types from the server
const migrate = (doc: SavedObjectUnsanitizedDoc | RawLensSavedXYObject770) => | ||
migrations['7.7.0'](doc); | ||
|
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.
Why not just const migrate = migrations['7.7.0']
?
On a higher level, that kind of specialized input type makes sense imho.
Maybe we should adapt
kibana/src/core/server/saved_objects/migrations/types.ts
Lines 42 to 45 in 8524303
export type SavedObjectMigrationFn = ( | |
doc: SavedObjectUnsanitizedDoc, | |
context: SavedObjectMigrationContext | |
) => SavedObjectUnsanitizedDoc; |
to
export type SavedObjectMigrationFn = <
InputDocDocType extends SavedObjectUnsanitizedDoc = SavedObjectUnsanitizedDoc,
MigratedDocType extends SavedObjectUnsanitizedDoc = SavedObjectUnsanitizedDoc
>(
doc: InputDocDocType,
context: SavedObjectMigrationContext
) => MigratedDocType;
@rudolf WDYT?
Also I think you already stated in another PR that we did not really want to export the SavedObjectUnsanitizedDoc
type. Can you confirm or infirm that? For their usage and the type check they are performing, I think they gonna need this type.
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.
Yeah I agree, a more specific type can be really useful for making sure there's no exceptions in migration code. In the future, I imagine we would add saved object validation with kbn-config-schema or io-ts and then this type would provide 100% certainty that you won't get "value of undefined" exceptions.
There was a previous PR where the PR used SavedObjectUnsanitizedDoc
instead of the SavedObjectMigrationFn
type. Using SavedObjectMigrationFn
makes it easier to change the API in the future, most likely for changes to context: SavedObjectMigrationContext
.
In this PR I'm not sure if using SavedObjectUnsanitizedDoc
is helpful either because it requires narrowing the type with a type guard. A migration can only ever receive documents of it's type (@pgayvallet correct me if I'm wrong), so this is actually a bug in core's types or just our types being so loose they're misleading.
So unless there's some value to using this type that I'm not seeing, I'd suggest we don't export or use SavedObjectUnsanitizedDoc
in this PR.
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.
Okay, I'm going to get rid of these type checks.
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.
A migration can only ever receive documents of it's type (@pgayvallet correct me if I'm wrong),
You are right (...)
so this is actually a bug in core's types or just our types being so loose they're misleading.
The main issue regarding typings here is that there is no TS link between a SavedObjectsType
(or even SavedObjectsType.mappings
) and it's associated object's properties (SavedObject<Properties>
) and even less with the raw type we are using for migrations SavedObjectUnsanitizedDoc
, meaning that there is ATM no way to automatically infer the types for the migration function input or output.
This is why adding generic types to SavedObjectMigrationFn
sounds to me like a quick win to allow plugin developers to specify the input/output without having to manually redefine the signature.
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 don't have a problem per se with using SavedObjectUnsanitizedDoc
but not sure if it's adding value and if it's not I'd rather us not expose it.
const migrate = (doc: SavedObjectUnsanitizedDoc | RawLensSavedXYObject770) => | ||
migrations['7.7.0'](doc); | ||
|
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.
Yeah I agree, a more specific type can be really useful for making sure there's no exceptions in migration code. In the future, I imagine we would add saved object validation with kbn-config-schema or io-ts and then this type would provide 100% certainty that you won't get "value of undefined" exceptions.
There was a previous PR where the PR used SavedObjectUnsanitizedDoc
instead of the SavedObjectMigrationFn
type. Using SavedObjectMigrationFn
makes it easier to change the API in the future, most likely for changes to context: SavedObjectMigrationContext
.
In this PR I'm not sure if using SavedObjectUnsanitizedDoc
is helpful either because it requires narrowing the type with a type guard. A migration can only ever receive documents of it's type (@pgayvallet correct me if I'm wrong), so this is actually a bug in core's types or just our types being so loose they're misleading.
So unless there's some value to using this type that I'm not seeing, I'd suggest we don't export or use SavedObjectUnsanitizedDoc
in this PR.
import { SavedObjectUnsanitizedDoc } from 'src/core/server'; | ||
|
||
export interface RawLensSavedXYObject770 { | ||
type: 'lens'; |
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.
by changing type: string
RawLensSavedXYObject770
is compatible with SavedObjectUnsanitizedDoc
and then the type guards can be removed.
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
Tested with the same configurations as in the PR #62877 |
* [Lens] Migration from 7.7 * Fix types * Fix types in test * Add docs * Commit forgotten file * Remove extra types Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* [Lens] Migration from 7.7 * Fix types * Fix types in test * Add docs * Commit forgotten file * Remove extra types Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* alerting/alert-services-mock: (107 commits) removed unused import added alert services mock and use it in siem [Metrics UI] Refactor With* containers to hooks (elastic#59503) [NP] Migrate logstash server side code to NP (elastic#63135) Clicking cancel in saved query save modal doesn't close it (elastic#62774) [Lens] Migration from 7.7 (elastic#62879) [Lens] Fix bug where suggestions didn't use filters (elastic#63293) Task/linux events (elastic#63400) [Remote clusters] guard against usageCollection plugin if unav… (elastic#63284) [Uptime] Remove pings graphql (elastic#59392) Index Pattern Field class - factor out copy_field code for future typescripting (elastic#63083) [EPM] add/remove package in package settings page (elastic#63389) Adjust API authorization logging (elastic#63350) Revert FTR: add chromium-based Edge browser support (elastic#61684) (elastic#63448) [Event Log] Adds namespace into save objects (elastic#62974) document code splitting for client code (elastic#62593) Escape single quotes surrounded by double quotes (elastic#63229) [Endpoint] Update cli mapping to match endpoint package (elastic#63372) update in-app links to metricbeat configuration docs (elastic#63295) investigation notes field (documentation / metadata) (elastic#63386) ...
* [Lens] Migration from 7.7 * Fix types * Fix types in test * Add docs * Commit forgotten file * Remove extra types Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This change is a copy & paste of a migration that Lens needs in 7.7- the migration code is the same, but inline comments highlight the differences. This is the reference: #62877