RailsのバージョンアップとRubyConf 2024のスピーカー募集
こんにちは、第23回のtanaken on Railsです。
This Week in Railsから、2つのお知らせと、2つのプレリクエストを紹介します。
お知らせの1つ目です。
Railsのバージョンアップありました。
6.1.7.8、7.0.8.4、7.1.3.4、そして7.2.0.β2と4つです。
Railsのセキュリティリリースあったので、各位バージョンアップをしましょうというお知らせでございます。
2つ目、RubyConf 2024のスピーカーの募集が始まりましたというお知らせです。
RubyConf 2024は、2024年の11月13日水曜日から15日金曜日の3日間でシカゴで開催されます。
スピーカーの募集は、2024年の6月6日、本日が6月8日なので、2日前から始まっておりまして、
来月7月8日の月曜日まで受け付けていると、1ヶ月ちょっと受け付けているということでございます。
続いてプレリクエストを紹介していきます。
まず1つ目、Allow 1 to Set String Loading Mode Globallyというプレリクエストです。
こちらはアクティブレコードに関する変更です。
第16回のTanake on Railsで紹介したストリクトローディングモードに関する変更が行われています。
第16回を詳しく聞いてみてほしいんですけども、
簡単にストリクトローディングモードについてお話しすると、
アクティブレコードでレコードが関連付けを遅延読み込みしようとした時の振る舞いを制御するというものですね。
ストリクトローディングモードにAllを指定すると、
全ての遅延読み込み、どんな遅延読み込みでもやろうとするとエラーになるようになります。
All以外だとNプラス1オンリーというモードもあって、
このモードを使うとNプラス1が発生するような遅延読み込みをするとエラーになるということになっています。
このストリクトローディングモードですが、
アプリケーション全体で有効にするのか無効にするのかを切り替えることができます。
こちらはRailsガイドにもちゃんと記載があって、
config.activerecord.strictloadingbydefaultというオプションがあります。
このstrictloadingbydefaultにTrueを指定すると、
デフォルトでアプリケーション全体でストリクトローディングになると、
遅延読み込みをエラーとするという感じですね。
デフォルトはフォルスですね。
無効で有効にしたいときはTrueを指定してくださいということでございますね。
ただこのstrictloadingbydefaultをTrueにした場合、
このときの挙動がストリクトローディングのモードとしては
すべてAllで有効になるという仕組みになっていました。
なのでAllなので、どんな遅延読み込みをしようとしても必ずエラーになるという感じですね。
なのでアプリケーション全体でAllにするのか、
全く指定しないのかという2択でしか選べなかったと。
個別のレコードに対してはNプラスオンリーモードが指定できるのに、
アプリケーション全体についてはAllかそれ以外かしか選べなかったということですね。
つまりNプラスオンリーモードをアプリケーション全体に指定する手段がない、
困ったなということだったということで、
今回のプレリクエストではこの状況に対して新しいオプションを追加して
AllなのかNプラスオンリーモードなのかを2択を選べるようになりました。
オプションの名前はconfig.activerecord.strictloadingmodeというオプションですね。
デフォルトはAll、既存の挙動のままでNプラスオンリーというのも指定できる。
Allの代わりにNプラスオンリーも指定できるようになったということですね。
有効にする場合はstrictloadingbydefaultをtrueにした上で
strictloadingmodeをNプラスオンリーというふうにすると
アプリケーション全体でNプラスオンリーモードが適用されるようになるということですね。
というプレリクエストでございました。
プレリクエストの2つ目、今回のコンテンツの最後ですね。
タイトルがDeferRouteDrawing to the First Request or When URL Helpers Calledというプレリクエストです。
こちらはレールタイズに関する変更です。
ルーティングの描画を最初のリクエストを受けたとき
またはURLヘルパーズというのが呼ばれたときまで遅延するという仕組みが実装されました。
これまではレールズランナーの実行だったり
テストの実行だったり
Rakeタスクの実行だったり
DBマイグレーションの実行とかね。
という場合にも常にルーティングを描画する
内部レールズアプリケーションのルーティングを
コマンドの実行時に描画するようになっていたということです。
ただ、例えばレールズランナーでちょっとデータを見ようかなみたいなときって
ルーティングってどうでもいいというか別に気にしてないんですよね。
そういった場合にも常にルーティングの
ルーティングを準備するような処理が内部的に走っていたということで
これって不要なシーンがあるんだよなということに気づいた人がいたということで
特にルーティングがすごいたくさんあるようなアプリケーションにおいては
そのルーティングの準備にかかる時間で結構それなりに時間がかかっていて
時間がもったいないというところでこの時間を削減したいぞというので
プルリクエストが出されたということですね。
プルリクエストの中には実際にこの実装をした後とする前とで
比較の実験をしていて
ルーティングが2000件あるアプリケーションを題材として
レールズランナーの実行をしてみましたという結果が載っていました。
実装前の段階では0.6秒かなかかっていたところが
実装後は0.4秒、0.66秒から0.47秒かという形で削減されていますということで
およそ0.2秒の高速化が実現されていますよということが示されていましたね。
ルーティングが2000件というのはどのくらいの規模なんだろうな
それなりにルーティングを細かく設計分けていたら
それくらいの規模になったりするのかなという感じではありますけどね
無駄な処理を遅延評価することで高速化していこうという取り組みになったということで
ありがたい限りだなと思います。
そんなところで今回はお知らせ2件とプレリクエスト2件を紹介しました。
こんなところで今週のたなきゃんオレリスは終わりにします。
ではまた来週。バイバイ。
