anchor.diff:  |`INT64`
   |`io.debezium.time.Timestamp` +
    +
  -Represents the number of milliseconds past epoch, and does not include timezone information.
  +Represents the number of milliseconds since the UNIX epoch, and does not include timezone information.
   
   |`INTERVAL DAY[(M)] TO SECOND`
   |`FLOAT64`
  
positive.code: }
  ----
  
  If we look at the `payload` portion, we see a number of differences compared with the _create_ or _update_ event payloads:
  
  * The `op` field value is now `d`, signifying that this row was deleted
  * The `before` field now has the state of the row that was deleted with the database commit.
  * The `after` field is null, signifying that the row no longer exists
  * The `source` field structure has many of the same values as before, except the `ts_ms`, `scn` and `txId` fields have changed
  * The `ts_ms` shows the timestamp that {prodname} processed this event.
  
  This event gives a consumer all kinds of information that it can use to process the removal of this row.
  
  The Oracle connector's events are designed to work with https://cwiki.apache.org/confluence/display/KAFKA/Log+Compaction[Kafka log compaction],
  which allows for the removal of some older messages as long as at least the most recent message for every key is kept.
  This allows Kafka to reclaim storage space while ensuring the topic contains a complete dataset and can be used for reloading key-based state.
  
  [[oracle-tombstone-events]]
  When a row is deleted, the _delete_ event value listed above still works with log compaction, since Kafka can still remove all earlier messages with that same key.
  The message value must be set to `null` to instruct Kafka to remove _all messages_ that share the same key.
  To make this possible, by default, {prodname}'s Oracle connector always follows a _delete_ event with a special _tombstone_ event that has the same key but `null` value.
  You can change the default behavior by setting the connector property xref:oracle-property-tombstones-on-delete[`tombstones.on.delete`].
  
negative.code: 
  |===
  
  Because _truncate_ events represent changes made to an entire table, and have no message key, in topics with multiple partitions, there is no guarantee that consumers receive _truncate_ events and change events (_create_, _update_, etc.) for to a table in order.
  For example, when a consumer reads events from different partitions, it might receive an _update_ event for a table after it receives a _truncate_ event for the same table.
  Ordering can be guaranteed only if a topic uses a single partition.
  
  If you do not want to capture _truncate_ events, use the xref:oracle-property-skipped-operations[`skipped.operations`] option to filter them out.
  
  // Type: reference
  // ModuleID: how-debezium-oracle-connectors-map-data-types
  