Schema Contexts¶
A schema context represents an independent scope in Schema Registry, and can be used to create any number of separate “sub-registries” within one Schema Registry. Each schema context is an independent grouping of schema IDs and subject names, allowing the same schema ID in different contexts to represent completely different schemas.
Why use schema contexts?¶
You can logically group schemas by specifying schema contexts. By default, schemas live in the default context. By providing qualified names for schemas, you can group them into sub-registries with context-specific paths. This gives you the ability to have multiple schemas with the same subject names and IDs existing as unique entities within their different contexts. There are several advantages to this, including the ability to 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 .
.
Qualified subjects¶
A subject name can be qualified with a context, in which case it is called a qualified subject. When a context qualifies a subject,
the context must be surrounded by colons. An example is :.mycontext:mysubject
.
Learn more about schema contexts¶
Schema contexts are used extensively for Schema Linking, but can also be used independently of that feature as needed.
For a complete guide to schema contexts, see Schema contexts within Schema Linking. That section 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
Additionally, the Schema Linking Quick Start includes examples of working with both subjects in the default context (unqualified subjects) and named contexts (qualified subjects).