「変更がなくてもupdated_atを強制的に更新して欲しい」というクライアントの要望に応えるためにwill_change!を使用したが、うまくいかない時があったのでメモ。
update!の前に、「在庫数が変更されるよ!」というフラグを立てる1行を追加した。
@zaiko.num_will_change!
@zaiko.update!(zaiko_params)
しかし、updated_atは更新されない。変だなーと思ってrails consoleで調べてみたら、以下のようになった。
irb(main):080:0* z.num
=> 2
irb(main):081:0> z.num_will_change!
=> 2
irb(main):082:0> z.num_changed?
=> true
irb(main):083:0> z.attributes = {:num=>2}
=> {:num=>2}
irb(main):084:0> z.num_changed?
=> false
num_will_change!を使った後、そのnumを再設定してしまうと、以前のフラグが消えてしまい再度判定されてしまう。ということは、再設定される可能性がない属性に対してwill_change!をしなければならない。候補は、id, created_at, updated_atしかない。idは変な動きをされてしまうと嫌なので却下。まあ、ここはupdated_atを変更したいのだから、updated_at_will_change!を使うのが無難なのかな。ということで、採用したが、これがうまくいかない。というのも、updated文は実行されるが、前と同じ値が設定されてしまう。updated_atを明示的に設定したと判断されてしまうようだ。では、created_atを採用した場合はどうか、というと、この時に実行されるupdate文ではcreated_atも変更されてしまう。もちろん、変更前と同じ値なので無害ではあるのだけど、何だか気持ちが悪い。
ということで、結論は、updated_atを明示的に設定する!
@zaiko.updated_at = Time.now
@zaiko.update!(zaiko_params)
なお、@zaiko.touchも考えたが、実際に変更があった場合は2回SQLが実行されることになるので却下した。
なおなお、save!の時は、save!前に属性の設定をしているから問題にならない。
@zaiko.num_will_change!
@zaiko.save!