Update requires a full object replacement.

Remarks:

• All non-updatable fields will be ignored. i.e. createdAt, id, tenantId and etc.
• Fields without ID will be treated as new field (with new ID) even everything remains the same.
  

Schema States

• draft
  • Schema can only be in this state from initial creation.
  • Integrations should not create object association to schemas in this state, because schemas can be modified and deleted without version bump.
  • All modifications result in inline update as non-breaking changes.
  • Allows deletion.
• active
  • It can be transitioned from draft or inactive.
  • Modifications will result in either breaking or non-breaking changes.
  • No deletion.
• inactive
  • It can be transitioned from active.
  • Cannot be modified nor deleted.
• State is shared across all versions. That is chagning a state on v3 will also affect v2, v1. In another word, state is not versioned.
• State transition cannot be done in the same request with other modifications. E.g. One cannot transition a schema from draft to active with fields removal.
  

Schema Versioning

Modifications can result in either breaking or non-breaking change. In general, a breaking change
is needed because the schema can be changed in a way that is no longer "correct" for all the existing data
of the schema. For instance, a schema with an optional field can be updated to become a required field as a
new version of it but still able to retain the historical context of the existing data. Version chain is
linear without branching. E.g Next version of 1.0 is 2.0 and 3.0 is the one after.

Non-breaking changes will result in an inline-update without creating a new version. E.g.
“v1” -> updates -> “v1” (id: bd1a4c6a-4470-4eba-bb26-4a76c26fd7ae and version number: 1.0).

• New choices in single-select or multi-select must be a superset.
• Field type cannot be changed.
• New field must be optional.
• No fields can be deleted.
• Optional field must remain optional.
  

Breaking changes will result in a new version. E.g. "v1" -> updates -> "v2"
(id: bd1a4c6a-4470-4eba-bb26-4a76c26fd7ae and version number: 2.0)

• Any changes that are not listed in the non-breaking changes section will be treated as breaking.
• Field deletion.
• New required fields.
• Single/Multi select choices are not superset of the original.
  

Note: Version chain is linear without branching.**E.g Next version of** 1.0 is 2.0 and 3.0 is the one after.

SCOPES

Requires seismic.custom_schema.manage, seismic.custom_schema.view. See Permissions for additional details.