2.2.4.6.5. 更新イベント

このテーブルの 更新 変更イベントの値は、実際にはまったく同じ スキーマ を持ち、そのペイロードは同じように設定されますが、異なる値を保持します。以下に例を示します。 

{
    "schema": { ... },
    "payload": {
        "before": {
            "id": 1
        },
        "after": {
            "id": 1,
            "first_name": "Anne Marie",
            "last_name": "Kretchmar",
            "email": "annek@noanswer.org"
        },
        "source": {
            "version": "1.0.3.Final",
            "connector": "postgresql",
            "name": "PostgreSQL_server",
            "ts_ms": 1559033904863,
            "snapshot": null,
            "db": "postgres",
            "schema": "public",
            "table": "customers",
            "txId": 556,
            "lsn": 24023128,
            "xmin": null
        },
        "op": "u",
        "ts_ms": 1465584025523
    }
}

これを 挿入 イベントの 値と比較すると、payload セクションにいくつかの違いがあります。

  • op フィールドの値は u になっており、更新によってこの行が変更されたことを示しています。
  • before フィールドは、データベースのコミット前の行と値の状態を表していますが、プライマリーキー列 ID に対してのみ表示され ます。これは、デフォルトで DEFAULT の REPLICA IDENTITY が原因です。
注記

行のすべての列で以前の値を確認する場合は、最初に ALTER TABLE customers REPLICA IDENTITY FULLを実行して customers テーブルを変更する必要があります。

  • after フィールドは更新された行の状態を持ち、ここで first_name の値が Anne Marie になっていることを確認できます。
  • source フィールド構造には以前と同じフィールドがありますが、このイベントは WAL の異なる位置からのものであるため、値は異なります。
  • ts_ms は、Debezium がこのイベントを処理したタイムスタンプを示します。

この ペイロード のセクションを参照することで学習できる点がいくつかあります。before と after の構造を比較 する と、コミットが原因で、この行で実際に何が変更されたかを判断できます。source 構造は、この変更の記録（トレーサビリティーを提供）に関する情報を示しますが、これにはこのトピックや他のイベントの他のイベントと比較できる情報があり、このイベントが他のイベントの前、後、またはその一部として他のイベントとして発生したかどうかを確認できます。

注記

行のプライマリーキー/一意キーの列が更新されると、行のキーの値が変更され、Debezium は 行の古いキーを持つ DELETE イベントと tombstone イベント、行の新しいキーを持つ INSERT イベントという 3 つ のイベントを出力します。