昨日の問題が解決？した。
はてなを付けてるのは、一応の対策はわかったけど理由がよくわからんから。
昨日↓の記事
対策
昨日以下のようにしてたところを、
$ bin/rake db:migrate RAILS_ENV=production
このように変えれば動いた。
$ rake db:migrate RAILS_ENV=production
要はbin/rake -> rake。
疑問
springについて知ってから、
rake, railsの実行にはbin/を付けてたんだけど、今回の場合これが問題だったようだ。なぜなのかは分からない。挙動を見る限りはbin以下のbinstub実行時には環境変数がうまく読み込まれていないように見えるけれど。
それから、rails cしたときにも、実行の仕方によってDBのコネクション成否が異なるようなんだけど、これがrake db:migrateのときと方則性が違ってもはや何が何だかさっぱりわからない。
昨日bin/rake db:createは成功してた理由もよくわからない。
とりあえず、rails cとrake db:migrateを実行したときの成否パターンを以下にまとめてみた。
これら2つに対して、
bin/を付けるbundle execを付ける- 何も付けない
のそれぞれに
RAILS_ENV=productionを前に付けるRAILS_ENV=productionを後ろに付ける
というパターンを試した。
環境は昨日と同じ。
rails console
失敗するケース
$ rails c RAILS_ENV=production $ bin/rails c RAILS_ENV=production $ bundle exec rails c RAILS_ENV=production
成功するケース
$ RAILS_ENV=production rails c $ RAILS_ENV=production bin/rails c $ RAILS_ENV=production bundle exec rails c
まとめると、RAILS_ENV=productionが前にあると成功、後ろにあると失敗する。rails, bin/rails, bundle exec railsは関係なし。
あと、ここでの「成功」はエラーが出ずにコンソールが起動することを言ってる。そこでDBにアクセスしようとするとエラーになったケースもあったような気がする。。
rake db:migrate
失敗するケース
$ bin/rake db:migrate RAILS_ENV=production $ RAILS_ENV=production bin/rake db:migrate
成功するケース
$ rake db:migrate RAILS_ENV=production $ RAILS_ENV=production rake db:migrate $ bundle exec rake db:migrate RAILS_ENV=production $ RAILS_ENV=production bundle exec rake db:migrate
まとめると、rake, bundle exec rakeは成功、bin/rakeは失敗する。RAILS_ENV=productionの前後は関係なし。
まとめ
こういう結果になる理由が全然わからなくてものすごく気持ち悪いんだけど、今はこれ以上深堀りせず先に進むことにする。
これは後でレベルが上がってから振り返ったらなんてことなく理解できるパターンのような気がする。
疲れた。
