マイグレーションファイルによらないdb/schema.rbの記述をなくしたい

[unikounio]

概要

mainブランチをbin/rails db:migrateするとdb/schema.rbに差分が出るようになっています。 db/schema.rbにマイグレーションファイルによって生成されたもの以外の記述が含まれているようなので、その記述を削除したいです。

スクリーンショット

[komagata]

db/schema.rbにマイグレーションファイルによって生成されたもの以外の記述が含まれているようなので、その記述を削除したいです。

こちら、どういう意味でしょうか？

この辺と同じかな？ Q＆A: rails db:migrate すると schema.rb の「limit: 255」が消えてしまう | FBC

[kyokucho1989]

私も同じ症状になりましたが、ローカルのデータベースを一旦削除したら差分がなくなりました。

https://bootcamp.fjord.jp/reports/91346

試してみてください。

[unikounio]

@komagata さん ご確認ありがとうございます✨ 理解不足で正しい説明ができていなかったようです💧

おっしゃる通り、ご提示いただいたQ&Aで起こっていることと同じだと思われます。 以下、自分の認識とお伝えしたいことを再度整理してみました。 ズレている箇所等あろうかと思いますので、ご教示いただけますと幸いです🙏

起こっていること

mainブランチでbin/rails db:dropしたあとに、

• bin/rails db:create db:migrateしたとき： db/schema.rbに差分が発生する
• bin/rails db:setupしたとき： db/schema.rbに差分が発生しない

という状況になっています。

結構前からこの状態になっていたようなのですが、操作次第で解消したように見えるので、疑問が出てもすぐに解決とされていたようです。

解決したように見える理由

おそらく、DBを作成する際README通りにbin/setupを使った場合は、その後にbin/rails db:migrateしても、もう１度bin/setupしても、db/schema.rbに差分が発生しないからではないでしょうか。

なぜ最初にbin/setupするとdb/schema.rbに差分が発生しなくなるのか

私の結論としては、「差分が発生するはずのマイグレーションファイルが適用されなくなるから」です。

これは、db/schema.rb の記述がdb/migrateディレクトリ内のすべてのマイグレーションファイルを適用した場合とは異なっている一方、db/schema.rbのバージョンがマイグレーションファイルのバージョンと一致する形で書かれているために起こっているようです。

以下に各コマンド実行時に起きていることを時系列で整理してみました。

1. db:setupを実行
   • セットアップの一環としてbin/rails db:prepareが実行される
     • DBが存在しないのでbin/rails db:setupと同様の処理が実行される
       1. rails db:createでDB作成
       2. rails db:schema:loadでschema.rbから直接テーブル作成
          • このときschema_migrationsテーブルが生成され、schema.rbのバージョン情報が記録される
       3. rails db:seed
2. bin/rails db:migrateまたはbin/setupを実行 ※ このとき、 bin/rails db:migrateとbin/rails db:prepareは同様の処理をする
   1. schema_migrationsテーブルとdb/migrateディレクトリ内のすべてのマイグレーションファイルを調べ、データベースの現在のバージョンと異なるバージョンがあるか照合する
   2. schema_migrationsテーブルとマイグレーションファイルのバージョン情報が一致しているので、マイグレーションファイルが適用されず、差分もでない

期待される振る舞い

bin/rails db:dropしたあとに

• bin/rails db:create db:migrate
• bin/rails db:setup

どちらを実行してもdb/schema.rbに差分が出ないようにしたいです。

そのために、db/schema.rb の記述をdb/migrateディレクトリ内のすべてのマイグレーションファイルを適用した場合と一致させたいです。

---

長々と書いてしまって読みにくい部分もあろうかと思いますが、何卒よろしくお願いいたします🙏

[komagata]

@unikounio schema.rbを作り直す処理をしてるか、してないかの差だと思います。

そして作り直した場合になんでlmit～が外れるかは僕もわかっていません。（カラムの並び順が違うという場合もあったとおもいます） 以前 @JunichiIto さんが調べてくださってその時もはっきりとはわからなかったとおもいます。（僕の記憶が確かならば・・・）

多分postgresqlのバージョンによってlimit～がついたり外れたり、カラム名の並び順が違ったりするんだと思います。

[unikounio]

@komagata さん ご確認ありがとうございます！

そして作り直した場合になんでlmit～が外れるかは僕もわかっていません。

この点、調べていく中で関連しそうなコミットがいくつかありました。 以下、ご意見をいただきたい点と合わせて共有させていただきます。

ご意見をいただきたい点

komagataさん的にschema.rbファイルの状態がどうあるべきと考えていらっしゃるのかをお伺いしたいです。

• ケースごとに今考えている対応
  • lmit～がついている状態が正 対応するマイグレーションファイルを追加する、もしくは現状維持
  • lmit～が外れている状態が正 既存のマイグレーションファイルからschema.rbを作り直す処理をして生じた差分をmainブランチにコミットする

経過

1. 元々db/migrateに沿ったschema.rbになっていた
2. https://github.com/fjordllc/bootcamp/commit/d0db2f1dc88f27b1d3d4d555004a69acd501d30d でschema.rbの変更が行われた
3. https://github.com/fjordllc/bootcamp/commit/0a274fff9ca2d731f83eb3845a08c5c4cef6ba53 でdb/migrateに沿った schema.rbに戻った
4. https://github.com/fjordllc/bootcamp/commit/134c6ea3e6983908c486ffe280078f00995f475e で2の状態に戻った

---

関連コミットの共有漏れ等、こちらのコメントに不備が多くて申し訳ないです💧 よろしくお願いいたします🙏

[komagata]

@unikounio

komagataさん的にschema.rbファイルの状態がどうあるべきと考えていらっしゃるのかをお伺いしたいです。

lmit～がついている状態が正

です。

@unikounio さんが触る前の状態を維持してください。今までもその状態で維持しており、今回のようなPRはたくさんありました。不要な変更点はcommitしなければ大丈夫です。commitは行単位でできます。

[unikounio]

@komagata さん なるほどです。 変更不要ということかと思いますので、本IssueはCloseさせていただきます。 ここまでご対応いただきましてありがとうございました🙏

[dowdiness]

@komagata

単純に疑問に思ったんですが、もしpostgresqlのバージョンによって挙動が変わるならdockerを使ってバージョンを指定した方が良いと思うんですがやらない理由があったりするんでしょうか？環境によって挙動が変わるのは普通に困るはずなので、管理出来るなら管理した方が良さそうに見えます。（正直dockerのことはよく分かってないです）

PS. 間違えてschema.rbの変更加えてすみませんでした

[komagata]

@dowdiness dockerのカリキュラムがbootcampにないからです。 卒業までの期間が長くなりすぎてしまう問題があり、dockerのカリキュラムはまだ導入していません。