3.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.1.2.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
    }
}

これを insert イベントの値と比較すると、payload セクションにいくつかの違いが表示されます。

  • op フィールド値は u、更新によりこの行が変更されたことを示すようになりました。
  • この before フィールドには、データベースのコミット前に値がある行の状態が表示されますが、プライマリーキーコラムだけが対象になります id。これは、デフォルトで REPLICA IDENTITY であるためです DEFAULT。
注記

行のすべての列の以前の値を表示するには、最初に customers テーブルを変更する必要があります。 ALTER TABLE customers REPLICA IDENTITY FULL

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

本 payload セクションのみで確認できる点がいくつかあります。コミットにより before、と after 構造を比較して、この行で実際に何が変更されているかを判断できます。この source 構造では、この変更に関する PostgreSQL のレコード（トレース可能性の向上）について説明しますが、重要なことは、このイベントや他のトピックの他のイベントと比較し、他のトピックで発生したイベントが他のイベントとして発生したか、または他のイベントとして同じ PostgreSQL コミットの一部として確認できるようにすることができます。

注記

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