概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: To join or not to join? An act of #includes 原文 公開日: 2017/08/07 著者: Tiago Farias 原文ではシェークスピアの古典劇『ハムレット』のセリフが多数引用されています。引用されたセリフのリンクをマウスオーバーするとシェークスピアの原文がポップアップします。 actの基本的な意味は「演技（する）」「（舞台の）場面」であり、タイトルはこれにかかっています。 2017/09/25: 初版公開 2021/09/22: 更新 訳注 k0kubunさんの以下の記事も合わせて読むことをおすすめします。Rails 5以降は#left_outer_joins（またはエイリアスの#left_joins)が使えます。また、#includesがActiveRecord::Baseを生成す

この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。 こんにちは、クリスマスの予定を聞かれてもnilを返すk−shogoです。今回はいつか役に立つかもしれないちょっとニッチなRailsの技を紹介します。 has_manyを拡張する Railsのhas_manyは自動的にリレーションを構築してくれて便利ですね。実はこのhas_manyのリレーションは拡張することが出来るのです。 さっそくサンプルを作成します。今回はUser,Group,UserGroupingの３つのモデルが存在し、UserとGroupはUserGroupingを介して多対多の関係を持つことにします。さらにUserGroupingには役割を示すroleカラムも持たせます。マイグレーションで示すと以下のようになります。 class CreateUserGr

Rails 5.1 以降で attribute_was, attribute_change, attribute_changed?, changed?, changed 等が DEPRECATION WARNINGRails 何が起きたか? Rails 5.1 へアップデートして大量に DEPRECATION WARNING や spec エラーが起きたので、調べてみると Rails 5.1 で ActiveRecord::AttributeMethods::Dirty の attribute_was attribute_change attribute_changed? changed? changed 辺りが非推奨になった。 参考: https://github.com/rails/rails/blob/ce93740a5e4437dfc1cf9b0b13da1bad06a2a598/

Rails5 になって ActiveRecord に or クエリが導入されました。早速、既存のコードを書き換えようとしたんですが、かなり慎重に使わないと結合順序のワナに嵌ってバグりそうで怖いです。 このような（間の抜けた）コードがあったとします。 Country. where(id: 1). where("id = ? OR id = ?", 1, 2). pluck(:id) 生成される SQL はこうで、 SELECT "countries"."id" FROM "countries" WHERE "countries"."id" = $1 AND (id = 1 OR id = 2) [["id", 1]] 実行結果はこう。 [ [0] 1 ] これを、or クエリを用いて素直に書き換えてみます。 Country. where(id: 1). where(id: 1).or(Cou

Ruby用のObject-Relational MapperであるActiveRecordを使っているときに、Polymorphicな関連先に対して更にPreloadする方法について触れます。 文脈 例えば、Twitterの通知一覧画面のような機能を開発しているとします。このとき、Model、Controller、Viewをそれぞれ以下のようなコードにしてみます。 Model # SVO = Subject + Verb + Object class Notification < ActiveRecord::Base belongs_to :object, polymorphic: true belongs_to :subject, class_name: "User" end class FavoriteNotification < Notification end class Ment

Ruby で DB を扱うちょっとしたスクリプトを書くとき、ActiveRecord で生SQLを使うと色々捗ることが多い。 そのためのメソッドをまとめてみた。 事前準備： establish_connection 作成・更新系： execute 検索系： select_all, select_one, select_rows, select_values, select_value プレースホルダ： sanitize_sql_array 事前準備 establish_connection DBとのコネクションを確立する。'mysql2', 'postgresql', 'redshift' など様々なアダプタが使える。 以下は接続設定の一例。 [MySQL] (要 mysql2 gem) require 'active_record' config = { adapter: 'mysql2

def hoge_search relation = HogeModel.preload(:fuga) relation = relation.where('created_at >= ?', params[:created_at_start]) if params[:created_at_start].present? relation = relation.where('created_at <= ?', params[:created_at_end]) if params[:created_at_end].present? relation = relation.where('updated_at >= ?', params[:updated_at_start]) if params[:updated_at_start].present? relation = relation.wh

RailsのChangeLogを読んでいたらkamipoさんの ActiveRecordへのコミットがRails5から使えるようになってるものがたくさんあったのでまとめてみました。 PostgreSQLでExpression IndexとOperator Classをサポート MySQLでPrepared statesmentsをサポート config/database.ymlでprepared_statements: trueとすると利用できるようになります。mysql2 0.4.4以降が導入されていないと使えないようです。 Schema dumperがcreate_tableブロックの中でindexを定義するようになった schema.rbのcreate_tableのブロック内でt.indexでインデックスが定義されるように変更されています。以前はcreate_tableのブロック外で

Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを

概要 ActiveRecordを利用したコーディングにおいて、NOT EXISTSとINNER JOINを組み合わせた、少し複雑なクエリが必要となった。 そこで、Arelを使用した、生のSQLを書かない方法で実装してみた。 Arelとは 第43回　Rails 3を支える名脇役たち その1 - Arel - Arelとは，「Relational Algebra」または「Active Relation」の略で，その名前から想像がつくとおり，ActiveRecordから派生した，「関係代数」をRubyのオブジェクトで取り扱うためのライブラリです。 ドキュメントによれば，Arelは， 面倒なSQLの生成を簡単にしてくれて， さまざまなデータベースシステムに対応している， 「フレームワークのフレームワーク」を目指して作られています。 つまり，Arelを使えば，DBの互換性やSQL文字列の生成などに惑

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

このエントリは Ruby on Rails Advent Calendar 2014 の 7 日目のエントリです。 前日は seri_k さんの「Turbolinksさんと上手く付き合う10の方法」でした。 お詫び WIP です。公開期限に間に合わない可能性があるため、まだ途中ですが先に公開してしまいました。 サンプルコード等を後ほど追記する予定です。 → 12/08 18:10 追記しました。 Rails のファットモデル問題 Rails で構築したアプリケーションが大規模になり機能が増えていくにつれてモデルが大きくなり、そのうち手がつけられなくなる問題は古くから指摘されています。これについてはもはや詳細を述べるまでもないと思うので割愛しますが、この問題は 2014 年になった今でも多くの開発チームを悩ませていると感じています*1。 このエントリでは、普段 Rails を業務で使いながら

ActiveRecordを支える技術 – Arelとは何者なのか? (全5回) その1 #activerecord#Arel#rails#ruby#sql 2014年 05月 04日 nishio Rails3, ActiveRecordからは、内部でArelと呼ばれるSQL生成用のライブラリが利用されています。 今回、Arelが内部でどのようにSQLを生成しているのかを調査したので、当ブログにて公開いたします。 ちょっと長くなってしまったため、全5回に分割しました。 以下、目次となります。 ActiveRecordを支える技術 – Arelとは何者なのか?(全5回) その1 [この記事]Arelについてなぜ調査しようと思ったのか、その背景と今後利用するサンプルコードを掲載しています。ActiveRecordを支える技術 – Arelとは何者なのか?(全5回) その2シンプルなSQL文、「

has_many，throughとかでモデルやテーブルの構成を考えるとき，どうしてもカラム名と関連づけるテーブルの名前が一致しなかったり，望み通りの命名で行けない場合がある． もちろん，一つのテーブルが，他のテーブルのレコードを複数持つだけなら，命名はスマートに決められるのだけれど． 今回の例題は，Userモデルに対するフォロー・フォロワーを実現すること． Userは一つのテーブルでなければならないことはわかりますよね． ということは，UserテーブルがUserFollowという中間テーブルを介して，Userテーブルのレコードをhas_manyするという形をとる． もうガリガリと書いていきます． まず，こういう，元から名前の統一が難しそうな場合はテーブルを先に作ってしまう． Userテーブル id name 1 poteto 2 hoge UserFollowテーブル id user_id

ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 では、関連先のscopeを使うことができるmergeを紹介しました。mergeを使う事で、変更に強いクエリを美しく組み立てることができました。 今回は、ActiveRecord4で書きにくいSQLクエリたちを紹介します。 書きにくいクエリとは、具体的には以下のものがあげられます。 比較演算ORlikeleft outer joinunionサブクエリexists ActiveRecordでこれらのクエリを組み立てる場合、どうしても美しくない（SQL文字列をべったり書いてしまうような）書き方となってしまいがちです。 この処理を美しく書くためには、ActiveRecordだけの機能では足りず、ActiveRecordが内部で使っているArelというライブラリを使う必要がでてきます。 今回は、Arelを使って華麗にSQLク

プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight プチ・デザインパターン的なやつ、僕もよくやってます。 で、運用エンジニア的にはデータの不整合を起こしうる要因はできる限りDB側の制約でも防ぎたいので、このusersとprofilesの場合だと、usersで自動採番されたidをprofilesでも使うのでprofilesの自動採番する機能は残しておくと事故るリスクがあるので落としたいわけです。 なので、僕はいつもこんな感じでmigrationを書いてます。 class CreateUsers < ActiveRecord::Migration def change create_table :users do |t| t.string :email, charset: 'ascii', collation: 'ascii_bi

インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC