2

初めて本番環境にデプロイする準備をしている多数の移行ファイルを含むアプリを持っているとしましょう。私が理解していることから、本番サーバーでデータベースを起動するには、基本的に2つのオプションがあります。

  • A - を実行db:migrateし、まだ実行していないすべての移行を循環させます
  • B - 実行db:schema:loadし、スキーマ ファイルからデータベースを構築します。

schema.rbコメントで説明されているように、B が新しい展開に適していることはわかっています。

# If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).

私が疑問に思っているのは、これが本番サーバーでの移行にどのように影響するかということです。たとえば、次のことを順番に行うとします。

  1. db:schema:load新しい本番サーバーで実行します。
  2. 開発中のスキーマを変更し、本番環境にプッシュします。
  3. db:migrate本番サーバーで実行

何が起こるか？アクションよりも新しい移行のみを使用することを認識しますかdb:schema:load、それともすべてを実行しようとしますか?

4

1 に答える 1

1

良い質問。答えは、最新のdb:schema:loadイベントの後に作成された移行のみが実行されるということです。

schema.rbファイルには、それに関連付けられたバージョン スタンプがあります。

ActiveRecord::Schema.define(version: 20130928225041) do ...

を実行するdb:schema:loadと、Rails はその schema.rb ファイルに従って新しいデータベースを作成し、同時にschema_migrations、スキーマのバージョン番号より前のバージョン番号を持つすべての移行をテーブルに入力します。

したがって、私が知る限り、Rails は基本的にその時点までのすべての移行を偽装しているだけで、実際には実行していません。(空の移行ファイルを生成し、ローカルで呼び出すことでこれをテストしましたdb:migrateが、サーバーに展開する前に移行ファイルにエラーを挿入しました。サーバーで を実行したところ、不適切db:schema:loadな移行がファイルに含まれていました。 schema_migrations テーブルは、明らかに実行されていないにもかかわらず、実行されたかのように表示されます)。

于 2013-09-28T23:17:13.330 に答える