́・_・`)原因News.columns_hash.keysは、そのモデルのカラム名を配列で返します。5未対応版の5.0.1が入っているとDBのカラムをそのまま配列にして返します。5対応版の5.1.0.beta2では、I18n対応したカラム名と同名のカラムを除いたものを返します。そのため返ってくる値がバージョンによって代わり、それに依存している処理がおかしくなります。この影響を受けるカラムは多くの場合参照できないため、通常は仕様ミスや顕在化してないバグの可能性が高いです。gemでは、あるモデルのカラムに対してtranslate指定をすることで、translate用のテーブルの同名カラムを参照するようになります。以下のようなNewsモデルがある場合を考えます。:descriptionendこのモデルのtitleとdescriptionはtranslateされているので、newsテーブルの同名のカラムは使われません。Globalizeによって、I18n対応した別テーブル(news_translates)の該当するlocaleのデータを取ってくるように変更されます。そのため、translateによって処理が上書きされたカラムと同じ名前のカラムが元のテーブルにあっても、アクセスすることは出来ません。5.0系ではcolumns_hash等で全てのカラムの一覧を取得した場合、このアクセス不能なカラムが一覧に入っています。そのため、上書き前のカラムがあるという前提のコードを書けてしまいます。"updated_at"]Globalizeの5.1系では、内部的に以下の方法でtranslateに設定されたカラム名が除外されるため、columns_hash等を使っても上書き前のカラムにアクセスできなくなります。"updated_at"]Rails4系の場合もとのcolumns_hashからtranslateしたカラムを消している。利用して上書き前のカラムがあることを前提としたコードを書いている場合、処理が失敗します。対策おそらくGlobalizeの意図している挙動は、translate設定したカラムは全てI18n対応のテーブルのものに完全に上書きするものです。アクセス出来てしまうのは予期せぬ事であり、上書き元にはアクセスしないようにするのが正しそうです。上書き元のカラムへのアクセスは普通に使っていると出来ません。translateしたカラムに対して処理を行っている場合は高確率で無駄な挙動かバグの可能性が高いです。これらのカラムはそもそもremove_columnsするべきですし、今後も増えないようにしていく必要があります。既存のカラムをtranslateしたような場合にtranslate前のカラムを消さずにそのまま残してしまうということはありえるため、増えないように注意するのは大変です。対策をgem化した毎回レビューでtranslateによって上書きされるカラムをチェックしするのは大変なため、そういったことをしてくれるgemを作りました。taskを提供します。globalize_overlap_checker:generate_remove_overlap_migrationこれにより、translateで上書きされるカラムの一覧と、それを消すmigrationを生成できます。initalizerの中で以下のように設定をする事で、この問題を避けることができます。GlobalizeOverlapChecker.prohibition_overlap!RAILS_ENV=testでこのメソッドを読ぶと、migration実行時にtranslateによって消えるカラムを見つけてエラーを起こしてくれます。これにより、translateしたのに残っているカラムの存在を検知出来るため、レビュー時に気をつける必要がなくなります。これらの機能により、今あるおかしいカラムを全部消すのと、今後増えるのを止めることが出来ます。5.1系にあげることでcolumns_hashを使っても上書き元のカラムにアクセスできなくなるため大きな問題は起きません。アクセスできないカラムは結局残るので、謎のカラムが増えることを防ぐのには依然として機能します。ota42yC++/Ruby/RoR/golang/rust/flutter。