週刊Railsウォッチ(20181217)Railsのafter_*系フックは要注意、早すぎるDRYとYAGNI、mruby 2.0リリースほか

こんにちは、hachi8833です。先日のRailsdm Day 4ではルームAで終日配信担当だったのでルームBの出し物がわからずじまいです。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを社内有志でつっついたときの会話です👄 毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください ⚓Rails: 先週の改修(Rails公式ニュースより) ⚓コレクションプロキシのdelete_allがcountを返すようになった PR: Ensure that `delete_all` on collection proxy returns affected count by kamipo · Pull Request #34609 · rails/rails # activerecord/lib/active_record/associations/has_many_association.rb#L99 count = delete_count(method, scope) update_counter(-count) + count end つっつきボイス:「ActiveRecordのdelete_なんちゃらメソッドはcountを返すんですが、それがdelete_allの場合返ってなかったので修正したということですね」「コレクションプロキシというのが今ひとつわからなくて」「自分も何が違うのか今までよくわかってなかったので調べたんですがどうやら以下みたいです」 CollectionProxy: has_manyとかを単独で呼び出した時のインスタンス user.posts.class => Post::ActiveRecord_Associations_CollectionProxy Relation: whereとかで絞った時のインスタンス user.posts.where(‘id > 5’).class => Post::ActiveRecord_AssociationRelation 「このcountって『10件殺した』みたいな数なんでしょうか?」「ふむむ…affected countということだからそうでしょうね」 「ちなみにRailsの影響の及ばない低レイヤだと、DAO(データアクセスオブジェクト)やデータベース系の関数は、削除や更新に成功したときに1、失敗したときにそれ以外の数値を返すという挙動のものが多いですね」「へぇ〜😳」「この場合Rails側で吸収してそれっぽくしてるのかも」 参考: Data Access Object - Wikipedia 追いかけボイス ⚓unpermitted paramsログのメッセージに色を表示 PR: Colorize the unpermitted params log message by blahed · Pull Request #34617 · rails/rails # actionpack/lib/action_controller/log_subscriber.rb#L def unpermitted_parameters(event) debug do unpermitted_keys = event.payload[:keys] – “Unpermitted parameter#{‘s’ if unpermitted_keys.size > 1}: #{unpermitted_keys.map { |e| “:#{e}” }.join(“, “)}” + color(“Unpermitted parameter#{‘s’ if unpermitted_keys.size > 1}: #{unpermitted_keys.map { |e| “:#{e}” }.join(“, “)}”, RED) end end つっつきボイス:「colorメソッドってこうやって使えるのか!」「paramsはいわゆるstrong parametersでしょうか?」「だと思います」「色が付くようになったのはいいな☺️」 参考: color — ActiveSupport::LogSubscriber ⚓ActiveJob::Base#enqueueがfail時にfalseを返すようになった PR: Make AJ::Base#enqueue return false if the job wasn’t enqueued by kirs · Pull Request #33992 · rails/rails このパッチを当てる前は、before_enqueueでコールバックチェインがabortされた可能性がある場合にジョブが実際にenqueueされたかどうかを確認する手段がなかった。 class AbortBeforeEnqueueJob < ActiveJob::Base before_enqueue { throw(:abort) } end > AbortBeforeEnqueueJob.new.enqueue => #<AbortBeforeEnqueueJob:0xXXXXXX @arguments=[], @job_id=”0d5ef7b9-d32b-4c83-b8cf-44ec31e9d6d9″ … このパッチを当てることで、ジョブがenqueueされなかった場合にfalseを返すようになる。 > AbortBeforeEnqueueJob.new.enqueue => false この部分はActiveSupport::Callbacksの設計に従った。 コールバックチェインが停止した場合はfalseを返す。それ以外の場合はブロックの結果を返す。コールバックが設定されなかった場合はnilを返す。コールバックが設定されたがブロックが与えられなかった場合はtrueを返す。 #enqueueの戻り値が変わるのでbreaking changeと考えられるであろうことは承知しているが、よりよい制御のために変更する価値があると思う。 同PRより大意 つっつきボイス:「#enqueueに失敗したらfalseを返すと」「before_enqueueでコールバックチェインがabortされた可能性がある場合に…ってややこしい😅」「まあ確かにキューが溢れている場合なんかに#enqueueが失敗する可能性がまったくないわけではないから必要なのかも: ということは返り値もチェックしないといけないのかなー、#enqueue失敗したら例外出して欲しい気もするけど」 「お、テストコードを見るとActiveJob::Base.return_false_on_aborted_enqueueっていう設定があるし: configで挙動を変えられるようになったってことか」「return_false_on_aborted_enqueueがtrueならfalseを返し、そうでなかったらwarningを返す」 # activejob/lib/active_job/enqueuing.rb#L run_callbacks :enqueue do if scheduled_at … Continue reading 週刊Railsウォッチ(20181217)Railsのafter_*系フックは要注意、早すぎるDRYとYAGNI、mruby 2.0リリースほか