- All Superinterfaces:
IndexTransaction
public interface UpdateTransaction
extends IndexTransaction
Handling of index updates on the write path.
Instances of an UpdateTransaction are scoped to a single partition update
A new instance is used for every write, obtained from the
newUpdateTransaction(PartitionUpdate) method. Likewise, a single
CleanupTransaction instance is used for each partition processed during a
compaction or cleanup.
We make certain guarantees about the lifecycle of each UpdateTransaction
instance. Namely that start() will be called before any other method, and
commit() will be called at the end of the update.
Each instance is initialized with 1..many Index.Indexer instances, one per
registered Index. As with the transaction itself, these are scoped to a
specific partition update, so implementations can be assured that all indexing
events they receive relate to the same logical operation.
onPartitionDelete(), onRangeTombstone(), onInserted() and onUpdated()
calls may arrive in any order, but this should have no impact for the
Indexers being notified as any events delivered to a single instance
necessarily relate to a single partition.
The typical sequence of events during a Memtable update would be:
start() -- no-op, used to notify Indexers of the start of the transaction
onPartitionDeletion(dt) -- if the PartitionUpdate implies one
onRangeTombstone(rt)* -- for each in the PartitionUpdate, if any
then:
onInserted(row)* -- called for each Row not already present in the Memtable
onUpdated(existing, updated)* -- called for any Row in the update for where a version was already present
in the Memtable. It's important to note here that existing is the previous
row from the Memtable and updated is the final version replacing it. It is
*not* the incoming row, but the result of merging the incoming and existing
rows.
commit() -- finally, finish is called when the new Partition is swapped into the Memtable