Exception that is passed if the stream is cancelled by the client
Name of this EventType. The name is constrained by a regular expression. Note: the name can encode the owner/responsible for this EventType and ideally should follow a common pattern that makes it easy to read and understand, but this level of structure is not enforced. For example a team name and data type can be used such as 'acme-team.price-change'.
Indicator of the (Stups) Application owning this EventType.
Defines the category of this EventType. The value set will influence, if not set otherwise, the default set of validations, enrichmentStrategies, and the effective schema for validation in the following way: - Category.Undefined: No predefined changes apply. The effective schema for the validation is exactly the same as the EventTypeSchema. - data
: Events of this category will be org.zalando.kanadi.api.Event.DataChange. The effective schema during the validation contains org.zalando.kanadi.api.Metadata, and adds fields org.zalando.kanadi.api.Event.DataChange.data and org.zalando.kanadi.api.Event.DataChange.dataType. The passed EventTypeSchema defines the schema of org.zalando.kanadi.api.Event.DataChange.data. - Category.Business: Events of this category will be org.zalando.kanadi.api.Event.Business. The effective schema for validation contains org.zalando.kanadi.api.Metadata and any additionally defined properties passed in the EventTypeSchema directly on top level of the org.zalando.kanadi.api.Event. If name conflicts arise, creation of this EventType will be rejected.
Determines the enrichment to be performed on an Event upon reception. Enrichment is performed once upon reception (and after validation) of an Event and is only possible on fields that are not defined on the incoming Event. For event types in categories 'business' or 'data' it's mandatory to use metadata_enrichment strategy. For 'undefined' event types it's not possible to use this strategy, since metadata field is not required. See documentation for the write operation for details on behaviour in case of unsuccessful enrichment.
Determines how the assignment of the event to a partition should be handled. For details of possible values, see org.zalando.kanadi.api.Registry.partitionStrategies.
Compatibility mode provides a mean for event owners to evolve their schema, given changes respect the semantics defined by this field. It's designed to be flexible enough so that producers can evolve their schemas while not inadvertently breaking existent consumers. Once defined, the compatibility mode is fixed, since otherwise it would break a predefined contract, declared by the producer. List of compatibility modes: - CompatibilityMode.Compatible: Consumers can reliably parse events produced under different versions. Every event published since the first version is still valid based on the newest schema. When in compatible mode, it's allowed to add new optional properties and definitions to an existing schema, but no other changes are allowed. Under this mode, the following org.zalando.kanadi.api.EventTypeSchema.Type.JsonSchema attributes are not supported: not
, patternProperties
, additionalProperties
and additionalItems
. When validating events, additional properties is false
. - CompatibilityMode.Forward: Compatible schema changes are allowed. It's possible to use the full json schema specification for defining schemas. Consumers of forward compatible event types can safely read events tagged with the latest schema version as long as they follow the robustness principle. - CompatibilityMode.None: Any schema modification is accepted, even if it might break existing producers or consumers. When validating events, no additional properties are accepted unless explicitly stated in the schema.
The most recent schema for this EventType. Submitted events will be validated against it.
Required when partitionStrategy is set to org.zalando.kanadi.api.PartitionStrategy.Hash. Must be absent otherwise. Indicates the fields used for evaluation the partition of Events of this type. If set it MUST be a valid required field as defined in the schema.
Event Type Cleanup Policy. 'delete' will delete old events after retention time expires. 'compact' will keep only the latest event for each event key. The key that will be used as a compaction key should be specified in PartitionCompactionKey.
Operational statistics for an EventType. This data MUST be provided by users on Event Type creation. Nakadi uses this object in order to provide an optimal number of partitions from a throughput perspective.
Additional parameters for tuning internal behavior of Nakadi.
Authorization section for an event type. This section defines three access control lists: one for producing events EventTypeAuthorization.writers, one for consuming events EventTypeAuthorization.readers, and one for administering an event type EventTypeAuthorization.admins. Regardless of the values of the authorization properties, administrator accounts will always be authorized.
This field is used for event publishing access control. Nakadi only authorises publishers whose session contains at least one of the scopes in this list. If no scopes provided then anyone can publish to this event type.
This field is used for event consuming access control. Nakadi only authorises consumers whose session contains at least one of the scopes in this list. If no scopes provided then anyone can consume from this event type.
Intended target audience of the event type.
This is an optional field which can be useful in case the producer wants to communicate the complete order across all the events published to all the partitions.
Indicates which field represents the data instance identifier and scope in which ordering_key_fields provides a strict order.
Date and time when this event type was created.
Date and time when this event type was last updated.