Skip to main content

Editing Schemas

To edit a schema:

  1. Navigate to the Schemas folder of the application that contains the schema you want to edit.
  2. Click the schema to open it in read-only mode.
    The Schema Editor appears.
  3. Click Edit in the top-right corner of the Schema Editor.

Renaming a Schema

To rename a schema, right-click it and select Rename. Update the name as appropriate and press <Enter>.

You can also open the schema in the Schema Editor, click Edit, and then click the Edit icon adjacent to the name of the schema.

Another way to update the name of a schema is to open the schema in Edit view, go into the code view, and update the value in the title attribute.

Editing Schema Details Using the Editor

After you open a schema in Edit mode, you can update its details either using the Code view or the Editor view. If you're familiar with schemas and are used to working with them directly, use the Code view. If you're relatively new to schemas, we recommend using the Editor. This section offers guidance on how you can edit a schema using the Editor.

info

Published schemas can only be modified in the Schema Registry.

The Schema Editor Toolbar

The Schema Editor toolbar appears above the Schema Editor and offers the following controls:

FieldDescription
UndoReverts the last change made to the schema. Useful for correcting mistakes.
RedoRe-applies an action that was previously undone.
DefinitionsOpens the Schema Definitions modal where you can view and edit shared components or reusable definitions. See creating-and-managing-definitionsfor more information.
DiscardDiscards all unsaved changes made to the current schema.
ExportDownloads the current schema in JSON format.
Code ViewSwitches the editor to display raw schema code in JSON.
UI ViewToggles the visual UI editor, offering a form-based way to edit the schema.
SaveSaves the current schema. This typically updates the stored or working version.
Generate SchemaAutomatically generates a schema based on defined prompts.
CloseCloses the schema.

The Schema Editor

Each row in the Editor refers to a schema element.

  • At the top of the schema, you can see the root element.
  • If the element is a node, the Editor displays controls that enable you to expand or collapse the node.
  • Similarly, if the element is an array, you can see the Array icon adjacent to it, and an items placeholder appears under the array node, which you can update with values as required. You can also define the data type of items in the array using the data type icons listed in the Select Type field-set.

Select the Required check box adjacent to an element to indicate that it's mandatory.

Click Add to enter a new attribute.
The Add Attribute modal appears. Use this modal to provide details associated with the attribute you want to add.

You can update properties associated with other attributes in the schema as well, without having to leave the Add Attribute modal. You can either Search for nodes or use the Back and Next buttons to display properties associated with specific attributes.

Schema Attribute Controls

Here's a table that provides guidance on each of the fields available to you in the Add Attribute modal:

FieldRequired?Available for Attributes of TypeData TypeDescriptionExample
NameRequiredAll Attribute TypesStringThe name of the property.product_id
DefaultOptionalString, Boolean, Number, IntegerStringThe default value of the property.PROD-0001
DescriptionOptionalAll Attribute TypesStringDescription of the attribute.The unique identifier of a product record.
ExampleOptionalString, Boolean, Number, IntegerStringExample of the property.PROD-1234
Select TypeMandatoryAll Attribute TypesStringThe data type of the attribute. Default = StringString
Schema Validation Options (allOf, anyOf, oneOf)OptionalNANAEnables complex validation rules. Options: allOf, anyOf, oneOf. See Schema Validation Options.allOf
FormatRequiredStringStringThe format of the string associated with the attribute.Object
RegexOptionalStringStringEnforces patterns using regex.^PROD-\d4$ (e.g., PROD-0023)
Min LengthOptionalStringIntegerMinimum character length.9
Max LengthOptionalStringIntegerMaximum character length.9
Min ValueOptionalNumber, IntegerIntegerMinimum numeric value.10
Max ValueOptionalNumber, IntegerIntegerMaximum numeric value.100
Min ItemsOptionalArrayIntegerMinimum number of array items.1
Max ItemsOptionalArrayIntegerMaximum number of array items.10
Content EncodingOptionalStringStringEncoding for binary data stored as string.base32
Content Media TypeMandatory if encoding is enabledStringStringOriginal type of encoded data.JSON
RequiredOptionalAll Attribute TypesBooleanMarks attribute as required.True
NullableOptionalAll Attribute TypesBooleanValue can be null. Not allowed if Required = true.False
MaskedOptionalAll Attribute TypesBooleanValue should be hidden when displayed/logged.True

Schema Validation Options

In a schema element's property settings, allOf, anyOf, and oneOf are keywords used for combining schemas, typically in JSON Schema. They allow you to define complex data structures by applying multiple validation rules to a single piece of data.

  • allOf (AND):

    • Meaning: The data must be valid against all of the subschemas listed in allOf.

    • Analogy: Think of it as a logical "AND". If you have allOf: [schemaA, schemaB], then the data must satisfy the rules of schemaA AND the rules of schemaB.

    • Use Case: Often used for extending a base schema or combining different sets of requirements. For example, if you have a Person schema and you want to define an Employee as a Person and someone with an employeeId and department, you'd use allOf.

    • Example:JSON

      {
      "allOf": [
      { "type": "string", "minLength": 5 },
      { "pattern": "^[A-Za-z]+$" }
      ]
      }

      This means the string must be at least 5 characters long and contain only letters.

  • anyOf (OR):

    • Meaning: The data must be valid against at least one of the subschemas listed in anyOf.

    • Analogy: Think of it as a logical "OR". If you have anyOf: [schemaA, schemaB], then the data must satisfy the rules of schemaA OR the rules of schemaB (or both).

    • Use Case: Useful when a property can have different valid forms or types. For instance, a field might accept either a string or a number.

    • Example:JSON

      {
      "anyOf": [
      { "type": "string" },
      { "type": "integer" }
      ]
      }

      This means the value can be either a string or an integer.

  • oneOf (XOR - Exclusive OR):

    • Meaning: The data must be valid against exactly one of the subschemas listed in oneOf.

    • Analogy: Think of it as a logical "Exclusive OR". If you have oneOf: [schemaA, schemaB], then the data must satisfy the rules of schemaA OR the rules of schemaB, but not both.

    • Use Case: Ideal for representing mutually exclusive options. For example, a payment method might be "credit card" or "bank transfer", but not both simultaneously.

    • Example:JSON

      {
      "oneOf": [
      {
      "type": "object",
      "properties": { "card_number": { "type": "string" } },
      "required": ["card_number"]
      },
      {
      "type": "object",
      "properties": { "bank_account": { "type": "string" } },
      "required": ["bank_account"]
      }
      ]
      }

      This means the object must have either a card_number or a bank_account, but not both.