Describe the layout of the data by using content metadata in the schema. For more information, see Metadata.

Why use a record topic?

A record topic enables multiple fields to be maintained in the same topic as part of a composite data type. All updates made at the same time to fields on a record topic are sent out to the client together. This enables a set of fields to be treated as a transactional group.

Deltas of change are calculated at the server such that only those fields that have changed since the last update are sent out to the subscribed clients. This ensures that the minimum amount of data is sent to clients.

Considerations when using a record topic

You must define the metadata when you create the record topic. This is more complex than using a JavaScript Object Notation (JSON) or Concise Binary Object Representation (CBOR) topic for composite data.

The metadata format used by record topics is only used by Diffusion. If you require a topic with a composite data type, you can use JSON or CBOR topics

Record topic updates represent all possible records and fields within the content. Fields that have not changed are sent within delta updates as zero-length strings. Because unchanged fields are represented this way a client cannot differentiate between a field that has not changed and an empty field. You can specify a special character that is used to represent an empty field.

The current value of a record topic is not cached on the client. Because of this, deltas are not processed automatically and your application code must cache the topic value and correctly apply incoming deltas. This lack of caching also requires that a client must register a stream against a topic before subscribing to the topic in order to receive a value. If a client subscribes to a record topic then registers a stream, the client receives only deltas until the next time a full value is published.