私の歴史と今

振り返ると恥ずかしくなるのが私の歴史。だけどそのときは真面目に書いていた訳でね。そんな今の私を書いていく。

updated_atが更新されなくて困った話

「変更がなくても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!前に属性の設定をしているから問題にならない。

# save!前に属性への設定
@zaiko.num_will_change!
@zaiko.save!