anchor.diff:  
   The `v2` column is left unchanged after this query and we don’t have any information about its previous value. 
   
  -We must be able to represent three possibilities: a column was not modified, a column was assigned a `NULL` value or a column was assigned a non-null value. The representation we chose was inspired by https://debezium.io/documentation/reference/1.6/connectors/cassandra.html[Debezium Connector for Cassandra], which works by wrapping the value for a column in a structure:
  +We must be able to represent three possibilities: a column was not modified, a column was assigned a `NULL` value or a column was assigned a non-null value. The representation we chose was inspired by link:/documentation/reference/1.6/connectors/cassandra.html[Debezium Connector for Cassandra], which works by wrapping the value for a column in a structure:
   
   [source,json]
   ----
  
positive.code: 
  A `null` structure value represents that a column was not modified (`v2` field). If the column was assigned a `NULL` value (`v3` field), there will be a structure with a `NULL` `value` field. A non-null column assignment (`v1` field) fills the contents of the `value` field. Such a format allows us to correctly represent all the possibilities and differentiate between assigning `NULL` and non-modification. 
  
  However, most sink connectors won’t be able to correctly parse such a structure. Therefore, we decided to develop our own SMT, based on Debezium’s https://debezium.io/documentation/reference/1.6/transformations/event-flattening.html[New Record State Extraction SMT]. Our https://github.com/scylladb/scylla-cdc-source-connector#scyllaextractnewstate-transformer[ScyllaExtractNewState] SMT works by applying Debezium's New Record State Extraction and flattening the `{"value": ...}` structures:
  
  [source,json]
  ----
  
negative.code: Alice |        2 | blueberries
  ----
  
  Looking only at this table, you cannot reconstruct all modifications that took place, e.g. Tim’s order name before the UPDATE. Let’s look at the CDC log, easily accessible as a table (some columns truncated for clarity):
  
  [source,sql]
  ----
  SELECT * FROM ks.orders_scylla_cdc_log;
  
   cdc$stream_id | cdc$time |     | cdc$operation | order_id | order_name  |     user
  ---------------+----------+-...-+---------------+----------+-------------+----------
      0x2e46a... |  7604... | ... |             2 |        1 |       apple |      Tim
      0x2e46a... |  8fdc... | ... |             1 |        1 |   pineapple |      Tim
      0x41400... |  808e... | ... |             2 |        2 | blueberries |    Alice
  ----
  
  All three operations are visible in the CDC log. There are two INSERTs (`cdc$operation = 2`) and one UPDATE (`cdc$operation = 1`). For each operation, its timestamp is also preserved in `cdc$time` column. The timestamp is encoded as a time-based UUID value as specified by the https://datatracker.ietf.org/doc/html/rfc4122[RFC 4122] specification, which can be decoded using helper methods in Scylla drivers.
  
  == Choosing Debezium
  
  