【実務・中級編】DataGripの「Time Machine（Local History）」機能でタイムトラベル？誤って実行したDELETEやDROP文からデータを奇跡的に復元する裏技 – データベース・API管理活用バイブル

「やらかした…」で終わらせない。DataGripのLocal Historyがあなたのキャリアを救う

開発現場において、`DELETE`や`DROP`は常に背中合わせの凶器だ。どれほど注意深くトランザクションを張っていても、深夜のデバッグ中に指が滑り、本番環境のレコードを消し飛ばす……そんな悪夢のような瞬間が誰にでも一度はあるだろう。

しかし、プロのエンジニアは「やらかした」後に慌てない。なぜなら、DataGripにはGitさえも補完する「Local History（ローカル履歴）」という、究極のタイムマシン機能が備わっているからだ。

今回は、Gitのコミット履歴に頼らず、DataGripが裏で勝手に記録している「全操作ログ」から奇跡的にデータを復元する禁断のテクニックを伝授する。

—

Gitは「明示的にコミットした時点」しか記録しない。しかし、DataGripのLocal Historyは、エディタ上で行われたすべての変更、コンソールの実行履歴、ファイルの保存状態を、Gitの介入なしにバックグラウンドで自動保存し続けている。

これは単なるバックアップではない。「どの瞬間に、どのSQLを投げ、その時エディタに何が書かれていたか」という、データベース操作の全タイムラインだ。

誤って`DROP TABLE`や`TRUNCATE`を実行し、真っ青になった時こそ、以下の手順を踏め。

1. 対象のファイル（またはコンソールタブ）を右クリック
2. 「Local History」 > 「Show History」を選択
3. 左側に過去の履歴がタイムスタンプ順に並ぶ。
4. 事故を起こす直前の状態を選択し、「Revert」をクリック。

これで、コンソール上のSQLスクリプトも、直前に書き換えてしまった設定ファイルも、すべて「事故が起きる直前」の状態に秒速で巻き戻る。

—

DataGripを単なるGUIツールとして使うのは、フェラーリで近所のコンビニに行くようなものだ。以下の設定で、生産性を限界まで引き上げろ。

`Ctrl + Shift + Enter` (Complete Current Statement): SQLの閉じ括弧やセミコロンを自動補完する。これが癖になると、タイポによるエラーが激減する。
`Ctrl + Alt + L` (Reformat Code): 汚いSQLを瞬時に整形。チームでこの設定を統一すれば、コードレビューの品質が跳ね上がる。
`Ctrl + Shift + F10` (Run Context Configuration): 選択範囲のSQLだけを即座に実行。複数スクリプトが混在する巨大なコンソールで、事故を防ぐ鉄則だ。

—

チームメンバーごとにDB設定がバラバラだと、不要な事故を招く。DataGripの設定はプロジェクト単位でGit管理するのが鉄則だ。

`.idea/` ディレクトリを共有する際、機密情報（パスワード等）は絶対に入れないこと。代わりに「データソースのテンプレート化」を行う。

`dataSources.xml`を直接編集するのではなく、環境変数やセキュアなパスワードストレージを併用する。

postgresql
true
jdbc:postgresql://${DB_HOST}:${DB_PORT}/${DB_NAME}
$ProjectFileDir$

チームの鉄則:
1. 読み取り専用モードの活用: 本番環境への接続は、DataGripの「Read-only」設定を必ず有効にする。
2. 色分け: 接続環境ごとにスキーマの色を変える（本番は赤、ステージングは黄色）。これは視覚的な事故防止の最後の砦だ。

—

DataGripで最も危険なのは、「自動コミット（Auto-commit）」が有効な状態で不用意に実行ボタンを押すことだ。

常に設定画面から 「Manual Commit」 モードであることを確認せよ。そして、もしトランザクションを忘れてデータを破壊してしまったら、慌てず騒がず「Local History」を開け。

テクノロジーは、我々のミスを許容するためにある。DataGripを使いこなすことは、単にSQLを書くことではない。「いかに安全に、そして高速に本番環境と対話するか」という、エンジニアの胆力を鍛えるプロセスそのものなのだ。

さあ、ツールを飼い慣らせ。あなたの指先一つで、開発の未来を安全なものに書き換えてくれ。