NestJsにおけるMigrationと「synchronize: true」を調べてみた

前回、いろいろと調べつつテーブルを作成した。その際、基本的に公式ドキュメントを参考にしたのだが、他ブログでは「マイグレーションファイルを作成」とかいう項目が散見された。フロントエンド専のため、理解が追い付かなかったので調べてみた。

目次

synchronize: true とは

公式ドキュメントを呼んでいる際は読み飛ばしたが、下記のようなことが書かれていた。

Setting synchronize: true shouldn’t be used in production – otherwise you can lose production data.

翻訳すると「設定synchronize: trueは本番環境では使用しないでください。そうしないと、本番データが失われる可能性があります。」とのこと。読み飛ばすにはあまりにも恐ろしい項目な気もするが、当時に自分は気にも留めなかった。

これがマイグレーション作業と深く結びついている。

synchronize: true

この設定は、アプリケーションをデプロイしたときにDBのテーブルがEntityから自動的に生成されるというもの。
そのため前回の記事のように、Entityを作成しセーブすることで自動的にテーブルが作成された。

どうやらすごく便利な設定だと思うようだが、危険もある。

Entityの状態がDBに同期されるため一見便利にみえますが、Entityのカラムを消したときにDBのカラムも消えてしまうため、誤ってPasswordのカラムを消してしまうなどのリスクがあります。

確かに誤って、コードを削除し、保存したらすべてのデータが消えるというのは非常に恐ろしい。

そこで本番に上げる前にsynchronize: falseにし、マイグレーションファイルを元に手動でDBの状態を更新するようにしていく必要がある。

Migrationとは

マイグレーションの正体は普通のJSファイルで、SQLを使用してデータベースのスキーマを更新したり、既存のデータベースに変更を加えるというものです。

つまり、同期的な変更ではなく、こちらでコマンドを行うことで、データベースを変更してくれる。

いざ、本番で操作するよりは、開発の時点でテスト的に触っておいた方が良さそうなので、どこかでテストする。その際、詳細な操作方法を追記する。

次に読むおすすめ記事

NestJSでOpenAPIツール「swagger」を生成する

NestJSのエラーレスポンスをカスタマイズする

LambdaにのせたNestJSでapp.enableCors();を指定しているのにCORSエラーがでたので解消するまでを記録した

NestJsにおけるMigrationと「synchronize: true」を調べてみた

NestJSでMySQLと接続するモジュールを外部化し環境変数にする

この記事に対するコメント

お気軽にコメントを下さい

メールアドレスが公開されることはありません。 が付いている欄は必須項目です