NestJsにおけるMigrationと「synchronize: true」を調べてみた
投稿日:2023年03月09日
最終更新日:2023年02月10日
前回、いろいろと調べつつテーブルを作成した。その際、基本的に公式ドキュメントを参考にしたのだが、他ブログでは「マイグレーションファイルを作成」とかいう項目が散見された。フロントエンド専のため、理解が追い付かなかったので調べてみた。
目次
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とclass-validatorでPOST時に検証をする
LambdaにのせたNestJSでapp.enableCors();を指定しているのにCORSエラーがでたので解消するまでを記録した
この記事に対するコメント