Confluent Developer Marketplace Get started
  1. Home
  2. Platform
  3. Manage Schemas on Confluent Platform
  4. Overview: Manage Schemas on Confluent Platform

Use Schema Contexts in Confluent Platform

A schema context is an independent scope in Schema Registry. You can use contexts to create any number of separate “sub-registries” within one Schema Registry. Each context is an independent grouping of schema IDs and subject names. The same schema ID in different contexts can represent different schemas.

Why use schema contexts?

Schema contexts let you group schemas logically. By default, schemas live in the default context. When you give schemas qualified names, you group them into sub-registries with context-specific paths. Schemas with the same subject names and IDs can then exist as unique entities in different contexts. Qualified names also let you provide specific contexts for different clients. Schema contexts are typically used in Schema Linking, where they provide mechanisms and flexibility for sharing schemas across registries.

Default context

Any schema ID or subject name without an explicit context lives in the default context, which is represented as a single dot ..

Compatibility applies per context, not globally across all contexts. To learn more, see Schema Evolution and Compatibility for Schema Registry on Confluent Platform.

All APIs that specify an unqualified subject operate in the default context. To pass the context, you can use a qualified subject wherever you would use a subject name, or use a base context path. A base context path takes the form /contexts/{context} and can be prepended to any existing Schema Registry path. For example, to look up a schema ID in a specific context, use the URL /contexts/.mycontext/schemas/ids/{id}.

You can also use a base context path to operate in the default context. In this case, the base context path takes the form /contexts/:.:/. For example, /contexts/:.:/schemas/ids/{id}. You can’t use a single dot because some URL parsers omit it.

The following curl example registers a schema under the .TestContext context:

curl -u <user>:<pass> \
-X POST -H "Content-Type: application/json" \
--url "https://psrc-gn6wr.us-east-2.aws.confluent.cloud/contexts/.TestContext/subjects/aContext2-value/versions" \
--data '{"schemaType": "AVRO", "schema":"{\"type\":\"record\",\"name\":\"test\",\"fields\":[{\"name\":\"field1\",\"type\":\"string\"},{\"name\":\"field2\",\"type\":\"int\"}]}"}'

The following curl example does the same for a Schema Registry running locally:

curl -X POST -H "Content-Type: application/json" \
--url "http://localhost:8081/contexts/.TestContext/subjects/aContext2-value/versions" \
--data '{"schemaType": "AVRO", "schema":"{\"type\":\"record\",\"name\":\"test\",\"fields\":[{\"name\":\"field1\",\"type\":\"string\"},{\"name\":\"field2\",\"type\":\"int\"}]}"}'

Qualified subjects

A subject name that includes a context is a qualified subject. Surround the context with colons, as in :.mycontext:mysubject.

Learn more about schema contexts

Schema Registry uses schema contexts extensively for Schema Linking, and you can also use them independently of that feature.

For a complete guide to schema contexts, see Schema contexts within Schema Linking. The guide includes:

  • Working examples

  • How contexts work

  • Default context

  • Qualified subjects

  • How to use a base context path

  • Multi-Context APIs

  • How to specify a context name for clients

The Schema Linking Quick Start includes examples of working with unqualified subjects in the default context and qualified subjects in named contexts.

Related content