※ 2019/4/25 追記:別途 rake task を用意する派だったが、管理する環境が増えてスクリプトの実行漏れが発生するので この記事で紹介されている migration_data という Gem が良さそうなので試してみたい。 とりあえずの結論 migration スクリプト内ではモデル独自のメソッド、アトリビュート等に依存した処理は書くべきでは無い それらのメソッド、アトリビュートはDBの物理的な構造に関係無く変更されるもの 将来それらを削除したり変更した際にmigrationが動かなくなる可能性がある どのメソッドが良くてどれがダメか判断が難しい場合、SQLを直に書くのもアリ ActiveRecordで生SQLを使いたいときに便利なメソッド達 - Qiita 発端 マイグレーションにより新しいカラムを追加するけど、その値をマイグレーションで入れるべきかについてプロジェクトで話
class AddNameToUser < ActiveRecord::Migration def change add_column :users, :name, :string User.find_each do |u| u.name = u.email.split("@")[0] end end end このファイルを使ってマイグレーションした時にはエラーは発生しない。しかし新たな環境にデプロイする時に謎のエラーが発生するかもしれない。 原因 ActiveRecord::Baseを継承したクラスはインスタンスを作成するタイミングで、データベーススキーマを確認する。 上記の例では、find_eachの中でusersテーブルのスキーマを確認し、Userクラスに保存しておく。 このスキーマ情報は各モデルクラスにキャッシュされる。インスタンス化のたびにスキーマを参照するわけにはいかないので当
TL;DR: use migration_data gem. Changing data in production is a common problem for Rails developers. Assume you have a Rails project. One day you decide to change the database schema and want to add some new column. Then you have to go through all existing records and change data to be actual according to this new schema. There are solutions to overcome this. But they have disadvantages. You will
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く