[第19回] 注文変更後に元の値も確認する — QueryPie DML Snapshot

第6回は変更権限を開き続けず必要SQLだけを承認実行した。今回は実行後、誰のSQLかに加えてデータがどう変わったかも確認したい。

架空注文1件をPENDINGからDELIVEREDへ変え、DML Snapshotを開いた。状態遷移が残り、処理を説明しやすかった。

実習DBでDML Snapshotを有効にする

Databases → DB ConnectionsのOrders Control Labで、追加設定のDML SnapshotをOffからOnにして保存した。

接続単位で有効にする機能だ。公式文書ではQueryPie経由で完了したINSERT・UPDATE・DELETEの変更前後を記録するとある。今回は既存MySQLでUPDATE1件を試す。

4003番はまだPENDINGだった

開発者がWeb SQLエディターで4003を参照すると、PENDING、18,500ウォンだった。

変更は状態だけ。番号と現状態PENDINGを条件にDELIVEREDへ変えるSQLを用意し、通常のRead-Onlyは維持した。

既存のSQL承認手順で変更する

Workflowで「注文4003の配送完了処理 — DML Snapshot確認」とし、接続、DB、SQL、理由を入力した。

既存規則でDemo Approverが承認、Demo Developerが申請・実行となった。SQLは次のとおりだ。

UPDATE orders_control.ordersSET status = 'DELIVERED'WHERE order_id = 4003  AND status = 'PENDING';

承認者が1件だけを対象にする条件を確認した。開発者に戻って実行すると「1 Rows updated」だった。

普段は参照し、変更時だけ承認SQLを使う。従来の手順を通しながら、今回は変更前後の記録も残せた。

実行UPDATEがDML Snapshotsに表示される

Audit → Databases → DML Snapshotsに、2026年11月9日00:17:13、Demo DeveloperのUPDATEがあった。

詳細には接続、テーブル、SQL、Rows 1、Executed From: SQL Requestがあり、承認経由の実行だと分かった。

BeforeとAfterで変化を見る

orders_control.ordersのBeforeには4003のPENDINGがあり、実行前の参照と一致した。

Afterは同じ注文のDELIVEREDだった。SQLと実際の値を一画面で見られて理解しやすかった。

処理前の状態を聞かれても、この記録で説明できる。別に作業者のメモを探さず前後を確認できる点がよかった。

実行履歴と変更内容を併せて確認する

同時刻のQuery AuditでもDemo DeveloperのUPDATEはSuccessだった。実行者と結果はQuery Audit、前後値はDML Snapshotで把握できた。

実行の有無だけでなく実際の状態変化まで分かった。通常参照権限は維持し、必要修正だけ承認し、実行後は前後が記録された。

運用変更の説明や監査準備にも役立ちそうだ。申請・承認、SQL、変化した値を順に確認でき、当時の記憶に頼る負担が減る。

QueryPie Community 11.6.7とMySQL 8.0.42で架空注文を使って実施した。

参考： QueryPie公式DML Snapshots文書