SO Model version: add support for `schema`

[pgayvallet]

We need to port an equivalent to the existing schemas type property for model versions:

kibana/packages/core/saved-objects/core-saved-objects-server/src/saved_objects_type.ts

Lines 73 to 80 in 7136039

	/**
	* An optional schema that can be used to validate the attributes of the type.
	*
	* When provided, calls to {@link SavedObjectsClient.create | create} will be validated against this schema.
	*
	* See {@link SavedObjectsValidationMap} for more details.
	*/
	schemas?: SavedObjectsValidationMap | (() => SavedObjectsValidationMap);

We should probably do that by adding a schema property to SavedObjectsModelVersion

kibana/packages/core/saved-objects/core-saved-objects-server/src/model_version/model_version.ts

Lines 20 to 25 in 7136039

	export interface SavedObjectsModelVersion {
	/**
	* The {@link SavedObjectsModelChange | changes} associated with this version.
	*/
	modelChange: SavedObjectsModelChange;
	}

So that the schema is more explicitly coupled with a given version.

Should probably be optional as it already was before model versions

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[TinaHeiligers]

@pgayvallet should we close this as handled in https://github.com/elastic/kibana/pull/156788/files#top or does the scope need to include implementing the validation?

[pgayvallet]

The scope needs to implement the validation, yes. There's likely not much to do now, just implement the SavedObjectsModelVersionSchemaDefinitions.create schema, and use it during create validation in the validation helper / type validator, here:

kibana/packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/apis/helpers/validation.ts

Lines 87 to 92 in 3b6b7ad

	/** Validate a migrated doc against the registered saved object type's schema. */
	public validateObjectForCreate(type: string, doc: SavedObjectSanitizedDoc) {
	if (!this.registry.getType(type)) {
	return;
	}
	const validator = this.getTypeValidator(type);

[TinaHeiligers]

We can't just take the latest stack version for documents that are already on 10.x.0 for choosing the validation schema to apply. We need to handle that now and change how the TypeValidator chooses the version with which to validate a doc needs to change.

[pgayvallet]

We need to handle that now and change how the TypeValidator chooses the version with which to validate a doc needs to change

Correct. We can no longer rely on the caller (the SOR) passing the target version to the type validator, as the version selection depends on whether or not the document is on a MV (10.x.0) version.

We need to move the logic of the version selection to within validate.

Something like

 public validate(document: SavedObjectSanitizedDoc, version?: string): void {
    // by default, we always use the version from the options if specified
    let usedVersion = version;
    if (!docVersion) {
      const docVersion =
        document.typeMigrationVersion ?? document.migrationVersion?.[document.type];
      if (docVersion) {
        usedVersion = isVirtualModelVersion(docVersion) ? docVersion : this.defaultVersion;
      } else {
        usedVersion = this.defaultVersion;
      }
    }
   // use `usedVersion` for the rest of the function
  // ...

Note that we could also simply remove the version option totally given I don't think we'll be needing it in the short term, which would translate to

 public validate(document: SavedObjectSanitizedDoc): void {
      let usedVersion: string;
      const docVersion =
        document.typeMigrationVersion ?? document.migrationVersion?.[document.type];
      if (docVersion) {
        usedVersion = isVirtualModelVersion(docVersion) ? docVersion : this.defaultVersion;
      } else {
        usedVersion = this.defaultVersion;
      }
        // use `usedVersion` for the rest of the function
      // ...