5.3.4.2.2. イベントの更新
このテーブルの 更新 変更イベントの値は実際には同じ スキーマ を持ち、ペイロードは同じですが、異なる値を保持します。以下に例を示します。
{
"schema": { ... },
"payload": {
"before": {
"id": 1005,
"first_name": "john",
"last_name": "doe",
"email": "john.doe@example.org"
},
"after": {
"id": 1005,
"first_name": "john",
"last_name": "doe",
"email": "noreply@example.org"
},
"source": {
"version": "1.1.2.Final",
"connector": "sqlserver",
"name": "server1",
"ts_ms": 1559729995937,
"snapshot": false,
"db": "testDB",
"schema": "dbo",
"table": "customers",
"change_lsn": "00000027:00000ac0:0002",
"commit_lsn": "00000027:00000ac0:0007",
"event_serial_no": "2"
},
"op": "u",
"ts_ms": 1559729998706
}
}
これを insert イベントの値と比較すると、payload セクションにいくつかの違いが表示されます。
-
opフィールド値はu、更新によりこの行が変更されたことを示すようになりました。 -
この
beforeフィールドには、データベースのコミットの前に値が含まれる行の状態が含まれるようになりました。 -
この
afterフィールドには更新された行の状態が使用されるようになりました。ここで、email値は現在の状態であることを確認できnoreply@example.orgます。 -
sourceフィールド構造には以前のフィールドと同じフィールドがありますが、イベントがトランザクションログ内の別の位置にあるため、値は異なります。 -
この
event_serial_noフィールドにはの値があり2ます。これは、背後にある 2 つのイベントで構成され、2 つ目のイベントのみを公開している更新イベントによって生じます。詳しくは、ソースのドキュメント を確認し、フィールドを参照してください$operation。 -
は
ts_ms、Debezium がこのイベントを処理したタイムスタンプを示しています。
本 payload セクションのみで確認できる点がいくつかあります。コミットにより before、と after 構造を比較して、この行で実際に何が変更されているかを判断できます。source 構造は、この変更の SQL Server の記録に関する情報を提供します（トレース可能性の向上）。より重要なことは、このイベントを他のトピックの他のイベントと比較し、このイベントが他のイベントとして発生したかどうか、または他のイベントの一部として確認することができます。
注記
行のプライマリー/一意キーの列が更新されると、行のキーの値が変更され、Debezium は 3 つ のイベント（ DELETE イベントおよび行の古いキーを持つコンブロック イベント） を出力し、行の新しいキーを含む INSERT イベントが出力されます。
