[第35回] WHEREを忘れたUPDATEとDELETEを止める

1件を変更するUPDATEでWHEREを忘れると他の注文も変わり、DELETEなら全行を消す可能性がある。

条件漏れの保護を有効にし、変更・削除権限で条件の有無を試して残存データを確認した。

変更・削除権限を用意する

DML Guard Labに35001・35002がPENDING、35003がTEMPORARYの架空注文を用意した。

SELECT・UPDATE・DELETEを付与し利用者画面でも確認した。これを維持してWHEREによる差を見た。

管理画面でWHERE保護を有効にする

Databases → General → Configurationsで、 Block UPDATE/DELETE without WHEREをOnにして保存した。WHEREなしUPDATE・DELETEを制限する全体設定だ。

保存確認後に開発者で新規接続し、以降は同じ接続で試した。

1件指定の変更は実行できる

WHERE work_id = 35001で状態をCHECKEDにすると、結果に 1 Rows updated.と表示された。

同じUPDATEからWHEREだけを外し、CHECKEDへの変更は同じで対象条件なしにした。

実行すると、 Query execution blocked 画面が現れ、案内に There is no WHERE clause foundとあり、条件漏れでQueryPieが止めたと分かった。

再参照すると35001だけCHECKED、35002はPENDING、35003はTEMPORARYで、条件なし変更は影響していなかった。

DELETEでも同じ差を確認する

TEMPORARYの35003をWHERE work_id = 35003で削除すると、 1 Rows deleted.と表示され、対象指定の削除は成功した。

WHEREなしのDELETE FROM ep35_guard.work_orders;は再びQuery execution blockedで条件不足と表示された。

35001 CHECKEDと35002 PENDINGが残り、指定削除の35003だけが消えた。

作業権限にミス防止を加えられる

必要な変更権限を付けたままWHERE漏れは別に止められた。同じ人・接続で対象指定は動き、条件なしは止まった。

日常変更への追加保護となる。管理者で設定し実行画面で理由を確認でき、1件処理の範囲が条件漏れで広がるのを防ぐのに役立ちそうだ。

QueryPie Community 11.6.7・MySQL 8.0.42のWeb SQLで架空データを使用した。終了後はデータを復元し、全体設定も元のOffへ戻した。

参考： QueryPie 11.6リリースノート · DAC General Configurations