"ActiveRecordの力でDBのメタデータを迅速に解析する" Reject on Rails 2024 での登壇資料です。 https://gotanda-rb.connpass.com/event/330965/ 実装したgemはこちら https://github.com/ln…
こんにちは。MySQLは秋の季語とする一派が世に存在していることを知り、私もMySQLに関わる記事を書いてみようと筆を取ることにしました。 さて、リレーショナルデータベースをバックエンドとするWebアプリケーション開発において、特定の条件に合致するレコードがN件だけ存在するかどうかを確認するロジックは頻出といえます。プログラマとして一度は書いたことがあるのではないでしょうか? この記事ではそのような件数カウントを行うためのクエリが引き起こした性能劣化と、その改善アプローチについて紹介していきます。 なお、本記事の内容はMySQLを前提としており、アプリケーションコードの例はRuby on Railsを用いますが特別な前提知識は必要ありません。コードの雰囲気だけ感じ取っていただければと思います。 ありがちなコード if query.count == n の問題 冒頭で述べた通り、特定の条件に
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ!!!— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
3行で できるだけ「文字列指定」ではなく「キー指定」を使いましょう where句にてテーブル名を指定するのは極力避けましょう activerecord-pretty-comparator gem を使うことで、文字列指定を使わざるを得なかった > もキー指定で書けます はじめに この記事では where('ends_at > ?', Time.current) のような書き方を「文字列指定」、 where(starts_at: ...Time.current) のような書き方を「キー指定」と呼びます 株式会社グロービスのslackにかみぽさんにJOINいただいており、不定期にRailsの困りごとを 壁打ち/相談 させていただいています この記事に出てくるコードは、実際のプロダクトコードをベースにしつつ問題を再現する最小のケースとして書いてみました Kaigi on RailsにCFP出した
NaClの前田です。 諸般の事情でRailsのコネクションプールを無効化したかったのですが、Rails 6では既存のgemやモンキーパッチでは動作しなかったため、古いモンキーパッチをベースにRails 6用のモンキーパッチを作成しました。 コネクションプールとは RailsではDB接続・切断をリクエストを処理する時に毎回行う代りに、リクエストの処理が終わった際にDB接続オブジェクトをコネクションプールに保持し、以後のリクエスト処理ではコネクションプールからDB接続オブジェクトを取得して使い回す仕組みになっています。 プールに保持するDB接続オブジェクト数の上限はconfing/database.ymlで以下のように指定します。 default: &default # ... pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> 環境変数RAIL
I have this ActiveRecord query issue = Issue.find(id) issue.articles.includes(:category).merge(Category.where(permalink: perma)) And the translated to mysql query SELECT `articles`.`id` AS t0_r0, `articles`.`title` AS t0_r1, `articles`.`hypertitle` AS t0_r2, `articles`.`html` AS t0_r3, `articles`.`author` AS t0_r4, `articles`.`published` AS t0_r5, `articles`.`category_id` AS t0_r6, `articles`.`iss
はじめに インデックスヒントはパフォーマンスチューニングにおいて欠かせないものの一つです。 今回はインデックスヒントとは何か、そして実際にRailsではどのように使うのか説明していきます。 実行計画について インデックスヒントを理解するため、前提として知っておきたい実行計画について説明します。 MySQLはオプティマイザというものを使用して、いい感じに実行計画(実行するクエリの詳細)を作成しています。 この実行計画はオプティマイザが以下の統計情報を参照して作成されています。 テーブルに含まれる行数 各インデックスのサイズ(ページ数) 各インデックスのリーフページのサイズ(ページ数) 各インデックスのカーディナリティ(何種類の値が存在するか?) ここで注意しなければならないことは、実行計画はあくまで推測であり必ず最適な訳ではないことです。 場合によってはMySQLが最適だと判断したクエリが、
A couple of weeks ago, we had a production outage for one of our internal Ruby on Rails application servers. One of the databases that the application connects to had a failover event. It was expected that the server should continue functioning for endpoints which do not depend on this database, but it was observed that our server slowed down to a crawl, and was unable to function properly even af
Active Record Query Logs Automatically append comments to SQL queries with runtime information tags. This can be used to trace troublesome SQL statements back to the application code that generated these statements. Query logs can be enabled via Rails configuration in config/application.rb or an initializer: config.active_record.query_log_tags_enabled = true By default the name of the application,
概要 MITライセンスに基づいて翻訳・公開いたします。 英語記事: Rails API ActiveRecord::NestedAttributes::ClassMethods 原文更新日: 2021/10/01(7d9b5d4) ライセンス: MIT Rails API: ActiveRecord::NestedAttributes(翻訳) Active RecordAttributesのネステッド版 ネステッド属性を使うと、関連付けられているレコードに親を介して属性を保存できます。ネステッド属性の更新はデフォルトでは無効になっており、accepts_nested_attributes_forクラスメソッドで有効にできます。ネステッド属性が有効になると、モデル上に属性ライターメソッドが定義されます。 この属性ライターメソッドは、関連付けに基づいて命名されます。つまり、以下の例ではモデルに
この記事は株式会社エス・エム・エス Advent Calendar 2023の17日目の記事です。 Railsアプリケーションのライフサイクルにおいて、データベーススキーマの適切な変更は、システムの整合性と拡張性を保つ上で不可欠な要素です。 本記事では、Active Recordがデータベーススキーマ情報をどのように取得し、キャッシュしているのか、そしてこれを利用してRailsアプリケーションがどのように動作するかについて掘り下げます。 それを踏まえて、スキーマ変更の適切なタイミングについて検討して行きます。 ※本記事で使用するRailsとDBのバージョンは、Rails 7.1.2とPostgreSQL 15.5です。 Active Recordとデータベーススキーマ Active Recordを通じて得られるスキーマ情報 Active Recordは、データベーススキーマに関する情報をD
先日、仕事でRails(Active Record)の難しい仕様に遭遇したので共有するためにエントリをしたためました。似たようなケースに遭遇した人の手助けになれば幸いです(\( ⁰⊖⁰)/) 対応Railsバージョンと設定 Rails6.1以上 config.active_record.has_many_inversing = true(Rails6.1のデフォルト設定)である 問題1 まず次のコードを読んでみてください。 class User < ApplicationRecord has_many :posts end class Post < ApplicationRecord belongs_to :user, inverse_of: :posts # (1) before_update { puts 'before_update' } end user = User.new po
ドキュメントを読み込むのは大事、ということでRailsガイドを頭から読んでいく取り組みをしています。 各章ごとに、(Railsガイドにちゃんと書いてあるのに)知らなかった機能を雑にまとめていきます。 今回は、Active Recordの関連付けの章です。 railsguides.jp reload_xxxと、changerd?previously_changed? リンクはこちら reload_xxx テストを書くときに、xxx.reloadみたいな使い方はよくしていましたが、関連モデルに使えるのは知りませんでした。 # (コンソールAで) book.user #=> #<User id: 1, email: "sample@example.com", created_at: ...> # (別のコンソールBで) User.find(1).update(email: 'sample02@e
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く