Profileモデルのカスタム ソート用に追加のフィールドが必要です。したがって、列の追加時に初期化する必要があります。
これを行うには、次の 2 つの方法があります。
そのようなことを書き留めてください
Profile.all.each { |p| p.update_attribute :sorted_at, p.created_at }
別の移行ファイルで。
2番目の解決策は良いですか、それとも悪いですか? そして、これらよりもはるかに優れた3番目のソリューションがあるのでしょうか?
データを更新するために特別に設計された db:seed rake タスクがあります。つまり、移行はスキーマの変更のみを対象とする必要があるということでした。
ただし、データの変更を移行から除外しようとした後、移行はデータの変更に適した場所であるという結論に再び達しました。結局のところ、必要なのは更新を 1 回だけ実行することであり、移行は実行済みの移行と実行する必要がある移行を追跡するため、1 回だけ実行されます。
私の経験則は次のとおりです。
1. アプリケーションを実行するためにデータベースに存在する必要がある初期データの場合は、seeds.rb スクリプトに配置します。つまり、お客様に納品されたときの初期状態の一部です。ユーザー インターフェイスはありません。データが後で削除された場合、有効な状態になることはありません。例として、ワークフローのステップがあります。
私は、seed_workflow_steps.rb のように、各テーブルに対して、seeds.rb が他のスクリプトを呼び出すようにしています。また、シード スクリプトは、データがテーブルに追加された後でも実行されるように作成する必要があります。ユーザーが意図的にレコードを削除する可能性のあるユーザー インターフェイスがあるデータには使用しないでください。シード タスクが再度実行されると、レコードが元に戻され、ユーザーの変更が取り消されるためです。
2. 移行に入れることができますが、それを格納するテーブルまたはフィールドを作成するための移行である場合に限ります。言い換えると、新しいテーブルまたは列を初期状態に初期化しているので、最初に機能が表示されたときに空白になることはありません。これには、ダウン マイグレーションによってテーブルまたはフィールドが削除され、データの作成が元に戻されるという利点があります。
3. それ以外の場合は、rake タスクまたはスクリプトに入れて、タスクまたはスクリプトを展開ステップとして実行します。優れた完全な開発プロセスには、開発者が展開のためのそのような追加の手順を文書化する方法が必要です。