Delta Publish Support

To accept delta publishes, the message type and the topic must both support delta publish. When this is not the case, AMPS accepts the publish, but may not produce the expected results.

All of the basic message types provided with AMPS support delta publish with the exception of the binary message type and protobuf message types that use protobuf version 3. Composite message types support delta publish if they use the composite-local definition, as described in the section on composite message types. Types that do not support delta publish, produce the full, literal message provided with a delta publish command (rather than merging the publish into the previous state of the message).

When a topic uses the composite-local message type, parts of the composite that are provided as empty (that is, zero-length) are considered to be unchanged, and the merged message contains the existing contents of that part. This provides a convenient way to update only one part of a composite message, without having to republish data that has not changed. For example, a composite-local type contains a JSON part and a binary part can modify the JSON part without having to republish the full binary part.

AMPS queues support delta publish to an underlying topic, if that underlying topic maintains a SOW. The merged message is provided to the AMPS queue.

All other AMPS topic types that are based on a SOW and accept publish commands support delta publish. AMPS topics that do not use a SOW do not support delta publish, so publishing a delta message to those topics produces the full, literal message from the publish command rather than a merged message. Without a SOW configured for the topic, AMPS does not track the current value of a message, and therefore does not have a way to merge the publish into an existing message.

Transaction Log Replay and Delta Publish

The AMPS transaction log stores the fully merged message. This means that, when the topic is also recorded in the transaction, a replay from the transaction log can provide all of the information in the message, not simply the delta. This can be particularly useful when one or more fields in the message is intended to be unchanged over a period of time: there is no need for a transaction log replay to reconstruct the message from an original publish that could be hours, days, or months in the past.

This also means that AMPS replication, since it is based on the transaction log, replicates the fully merged message. In general, this means that publishers that will operate on the same message should be grouped on the same AMPS instance, or should take care to sequence their updates so as not to overwrite other delta publishes.