16

現在、私は巨大な Rails アプリケーションと、このアプリケーションのそれぞれに新しい機能を備えた複数のブランチで作業しています。機能が移行を必要とすることはよくありますが、マスターとマージするまでは問題にはなりません: schema.rb は開発データベースの情報で更新されました!

明確にするために：

1. Branch A has migration create_table_x
2. Branch B has migration create_table_y
3. Branch A adds another create_table_z and runs db:migrate
4. You want to merge Branch A with Master and you see table_x, table_y and table_z in the schema.rb of Branch A.

ブランチでのすべての移行の前にデータベースをリセットしてシードするか、ブランチごとにデータベースを作成するオプションではありません。2 GB の SQL データはサイズが大きいため、実行できません。

私の質問：

schema.rb は移行ごとに再構築されるため、リポジトリに保持する必要は本当にありますか?

もしそうなら、データベースダンプの代わりに移行からスキーマを構築することは可能ですか?

4

3 に答える 3

2

新しい開発者 (またはテスト環境) が schema.rb から新しいデータベースを生成できるようにするため、schema.rb をリポジトリに保持することは重要です。多数の移行がある場合、移行が最初に実行されたときとは存在しない、変更された、または有効な検証が異なるモデル クラスに依存している場合は特に、すべてが実行され続けるとは限りません。テストを実行するときは、完全なテスト スイートを実行するたびにすべての移行を再実行するのではなく、schema.rb からデータベースをダンプして再作成する必要があります。

2 つの異なる機能ブランチに同時に取り組んでいて、両方のデータベース構造を変更している場合、schema.rb は問題が最も少ないと思います。ブランチ B の列の名前を変更または削除すると、古い列を参照するたびにブランチ A が破損します。彼らが新しいテーブルを作成するだけなら、それほど悪くはありませんが、master から A にマージするときに schema.rb を更新して、A が 2 回目の移行を実行しようとして失敗しないようにする必要があります。新しいテーブルが既に存在するためです。

それでも質問に答えられない場合は、ワークフローをもう少し説明していただけませんか?

于 2013-05-08T15:23:27.220 に答える
1

迅速な回避策としての新しい一時データベース

たとえば、db/schema.rb特定のブランチでかなり必要な場合は常に次のようにします。

  1. git チェックアウト -- db/schema.rb
  2. 別の開発データベースに切り替えます。つまり、config/database.yml を更新します。
  3. rake db:drop && rake db:setup
  4. rake db:移行
  5. きれいな db/schema.rb をコミットします
  6. config/database.yaml の変更を元に戻す
于 2015-05-11T20:38:47.603 に答える