[content management / maps] Content management / Saved object schema abstraction #155342
Conversation
…om:mattkime/kibana into content_management_api_so_type_abstraction
mattkime
changed the title
…om:mattkime/kibana into content_management_api_so_type_abstraction
…t_management_code_abstraction
…kime/kibana into content_management_code_abstraction
mattkime
changed the title
mattkime
added
Feature:Content Management
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
There was a problem hiding this comment.
LGTM
Out of scope for the work of this PR but I wonder if we don't want to leave the mapAttributesSchema (which is the main schema for a SO type) loose.
Only for the "result -> out" (so createResultSchema and objectTypeToGetResultSchema). Not for what comes "in" which should be strict.
Basically changing the { unknowns: 'forbid' } to { unknowns: 'allow / ignore' }. This would allow adding new fields without throwing when validating the schema. New fields are not breaking change and should also be fine in the UI. WDYT?
| export const schemaAndOr = schema.oneOf([schema.literal('AND'), schema.literal('OR')]); | ||
|
|
||
| // its recommended to create a subset of this schema for stricter validation | ||
| export const searchOptionsSchema = schema.object({ |
There was a problem hiding this comment.
Would it be better then to expose the properties separately for composing the schema then?
export const searchOptionsSchemaProperties = {
page: schema.maybe(schema.number()),
perPage: schema.maybe(schema.number()),
sortField: schema.maybe(schema.string()),
...
}
// consumer side
const { sortField } = searchOptionsSchemaProperties;
const mySearchOptionsSchema = schema.object({
sortField
});There was a problem hiding this comment.
Thats a good idea, will do.
I agree that its not necessary to have strict validation regarding new fields however it seems to me that we should have well defined schemas if possible. I think its the same as having good types with typescript code. |
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
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 @mattkime |
kibanamachine
added
v8.9.0
backport:skip
Summary
Abstract schema definitions for using Saved Objects with the content management api. For most schema types, this will reduce creation to only the attributes specific to a saved object. For Option types (create options, update options, search options) the saved object api is more complex and its likely that most SO types will only need to use a portion of it. In these cases we recommend using the provided schema definitions as a pattern for creating simpler schemas.
Follow up to - #154985 - expresses types in schema form